From xhpohanka at gmail.com Fri Feb 3 06:34:16 2012 From: xhpohanka at gmail.com (Jan Pohanka) Date: Fri, 03 Feb 2012 15:34:16 +0100 Subject: setup ofono for telit h910 on embedded system Message-ID: Hello, I'm working on embedded system with dm365 processor (arm926ej-s) and I want to use ofono with a Telit h910 modem connected by usb. The module works, I can make a calls using AT commands on /dev/ttyACM3 (or ttyS1), but I'm not able to register it with ofono. I have added following line to /lib/udev/rules.d/ofono.rules KERNEL=="ttyACM3", ENV{OFONO_DRIVER}="telit" (I have tried atgen also) After enabling the modem I'm getting following debug messages... ofonod[133]: plugins/udevng.c:udev_start() ofonod[133]: plugins/udevng.c:enumerate_devices() ofonod[133]: plugins/udevng.c:check_usb_device() MOSCHIP usb-ethernet driver [9710:7830] usb 1-1.3: new high speed USB device using musb_hdrc and address 5 usb 1-1.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing t o 11 usb 1-1.3: New USB device found, idVendor=058b, idProduct=0041 usb 1-1.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 1-1.3: configuration #1 chosen from 1 choice usb 1-1.3: USB disconnect, address 5 usb 1-1.3: new high speed USB device using musb_hdrc and address 6 usb 1-1.3: New USB device found, idVendor=1bc7, idProduct=0021 usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1.3: Product: Telit Wireless Module usb 1-1.3: Manufacturer: Telit wireless solutions usb 1-1.3: SerialNumber: 357164040028220 usb 1-1.3: configuration #1 chosen from 1 choice cdc_acm 1-1.3:1.0: This device cannot do calls on its own. It is not a modem. cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device cdc_acm 1-1.3:1.2: This device cannot do calls on its own. It is not a modem. cdc_acm 1-1.3:1.2: ttyACM1: USB ACM device cdc_acm 1-1.3:1.4: This device cannot do calls on its own. It is not a modem. cdc_acm 1-1.3:1.4: ttyACM2: USB ACM device cdc_acm 1-1.3:1.6: This device cannot do calls on its own. It is not a modem. cdc_acm 1-1.3:1.6: ttyACM3: USB ACM device cdc_acm 1-1.3:1.8: This device cannot do calls on its own. It is not a modem. cdc_acm 1-1.3:1.8: ttyACM4: USB ACM device cdc_acm 1-1.3:1.10: This device cannot do calls on its own. It is not a modem. cdc_acm 1-1.3:1.10: ttyACM5: USB ACM device cdc_acm 1-1.3:1.12: This device cannot do calls on its own. It is not a modem. cdc_acm 1-1.3:1.12: ttyACM6: USB ACM device ofonod[133]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[133]: plugins/udev.c:udev_event() subsystem tty add ofonod[133]: plugins/udev.c:udev_event() subsystem tty finished ofonod[133]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[133]: plugins/udev.c:udev_event() subsystem tty add ofonod[133]: plugins/udev.c:udev_event() subsystem tty finished ofonod[133]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[133]: plugins/udev.c:udev_event() subsystem tty add ofonod[133]: plugins/udev.c:udev_event() subsystem tty finished ofonod[133]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[133]: plugins/udev.c:udev_event() subsystem tty add ofonod[133]: src/modem.c:ofono_modem_create() name: (null), type: atgen ofonod[133]: src/modem.c:set_modem_property() modem 0xeebb0 property Path ofonod[133]: plugins/udev.c:add_modem() /devices/platform/musb_hdrc/usb1/1-1/1-1.3/1-1.3:1.6/tty/ttyACM3 (atgen) ofonod[133]: plugins/udev.c:udev_event() subsystem tty finished ofonod[133]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[133]: plugins/udev.c:udev_event() subsystem tty add ofonod[133]: plugins/udev.c:udev_event() subsystem tty finished ofonod[133]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[133]: plugins/udev.c:udev_event() subsystem tty add ofonod[133]: plugins/udev.c:udev_event() subsystem tty finished ofonod[133]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[133]: plugins/udev.c:udev_event() subsystem tty add ofonod[133]: plugins/udev.c:udev_event() subsystem tty finished ofonod[133]: plugins/udevng.c:check_modem_list() Unfortunately list-modems command still return nothing. Could please anybody here give me some advice how to solve the problem? best regards Jan -- Tato zpr?va byla vytvo?ena p?evratn?m po?tovn?m klientem Opery: http://www.opera.com/mail/ From oleg.zhurakivskyy at intel.com Mon Feb 6 04:33:53 2012 From: oleg.zhurakivskyy at intel.com (Oleg Zhurakivskyy) Date: Mon, 6 Feb 2012 14:33:53 +0200 Subject: [PATCHv2 0/8] Call forwarding state handling change Message-ID: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> Hello, Please find the changes in order to correct call forwarding states. Changes from v2: - Don't run conditional queries if cfu is active. - Clear the conditional cache flag on conditional deactivation while cfu is active. Regards, Oleg Oleg Zhurakivskyy (8): call-forwarding: Minor style fixes call-forwarding: Minor refactoring of is_cfu_enabled() call-forwarding: Don't set conditional cfs when cfu is active call-forwarding: Don't report conditional cfs when cfu is active call-forwarding: Emit signals to mask/unmask conditional cfs call-forwarding: Don't run conditional queries if cfu is active call-forwarding: Clear the conditional cache flag TODO: Remove completed call forwarding state task TODO | 17 ----- src/call-forwarding.c | 182 ++++++++++++++++++++++++++++++++++-------------- 2 files changed, 129 insertions(+), 70 deletions(-) -- 1.7.5.4 From oleg.zhurakivskyy at intel.com Mon Feb 6 04:33:54 2012 From: oleg.zhurakivskyy at intel.com (Oleg Zhurakivskyy) Date: Mon, 6 Feb 2012 14:33:54 +0200 Subject: [PATCHv2 1/8] call-forwarding: Minor style fixes In-Reply-To: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> References: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> Message-ID: <1328531641-10612-2-git-send-email-oleg.zhurakivskyy@intel.com> --- src/call-forwarding.c | 56 ++++++++++++++++++++++++++---------------------- 1 files changed, 30 insertions(+), 26 deletions(-) diff --git a/src/call-forwarding.c b/src/call-forwarding.c index a58ca21..731a38a 100644 --- a/src/call-forwarding.c +++ b/src/call-forwarding.c @@ -38,21 +38,19 @@ #define uninitialized_var(x) x = x -#define CALL_FORWARDING_FLAG_CACHED 0x1 -#define CALL_FORWARDING_FLAG_CPHS_CFF 0x2 +#define CALL_FORWARDING_FLAG_CACHED 0x1 +#define CALL_FORWARDING_FLAG_CPHS_CFF 0x2 /* According to 27.007 Spec */ #define DEFAULT_NO_REPLY_TIMEOUT 20 -static GSList *g_drivers = NULL; - enum call_forwarding_type { - CALL_FORWARDING_TYPE_UNCONDITIONAL = 0, - CALL_FORWARDING_TYPE_BUSY = 1, - CALL_FORWARDING_TYPE_NO_REPLY = 2, - CALL_FORWARDING_TYPE_NOT_REACHABLE = 3, - CALL_FORWARDING_TYPE_ALL = 4, - CALL_FORWARDING_TYPE_ALL_CONDITIONAL = 5 + CALL_FORWARDING_TYPE_UNCONDITIONAL = 0, + CALL_FORWARDING_TYPE_BUSY = 1, + CALL_FORWARDING_TYPE_NO_REPLY = 2, + CALL_FORWARDING_TYPE_NOT_REACHABLE = 3, + CALL_FORWARDING_TYPE_ALL = 4, + CALL_FORWARDING_TYPE_ALL_CONDITIONAL = 5 }; struct ofono_call_forwarding { @@ -72,10 +70,6 @@ struct ofono_call_forwarding { struct ofono_atom *atom; }; -static void get_query_next_cf_cond(struct ofono_call_forwarding *cf); -static void set_query_next_cf_cond(struct ofono_call_forwarding *cf); -static void ss_set_query_next_cf_cond(struct ofono_call_forwarding *cf); - struct cf_ss_request { int ss_type; int cf_type; @@ -83,6 +77,12 @@ struct cf_ss_request { GSList *cf_list[4]; }; +static GSList *g_drivers = NULL; + +static void get_query_next_cf_cond(struct ofono_call_forwarding *cf); +static void set_query_next_cf_cond(struct ofono_call_forwarding *cf); +static void ss_set_query_next_cf_cond(struct ofono_call_forwarding *cf); + static gint cf_condition_compare(gconstpointer a, gconstpointer b) { const struct ofono_call_forwarding_condition *ca = a; @@ -163,7 +163,8 @@ static GSList *cf_cond_list_create(int total, if (list[i].status == 0) continue; - cond = g_try_new0(struct ofono_call_forwarding_condition, 1); + cond = g_try_new0( + struct ofono_call_forwarding_condition, 1); if (cond == NULL) continue; @@ -497,7 +498,7 @@ static void property_append_cf_conditions(DBusMessageIter *dict, } static DBusMessage *cf_get_properties_reply(DBusMessage *msg, - struct ofono_call_forwarding *cf) + struct ofono_call_forwarding *cf) { DBusMessage *reply; DBusMessageIter iter; @@ -891,11 +892,11 @@ static DBusMessage *cf_disable_all(DBusConnection *conn, DBusMessage *msg, static GDBusMethodTable cf_methods[] = { { "GetProperties", "", "a{sv}", cf_get_properties, - G_DBUS_METHOD_FLAG_ASYNC }, + G_DBUS_METHOD_FLAG_ASYNC }, { "SetProperty", "sv", "", cf_set_property, - G_DBUS_METHOD_FLAG_ASYNC }, + G_DBUS_METHOD_FLAG_ASYNC }, { "DisableAll", "s", "", cf_disable_all, - G_DBUS_METHOD_FLAG_ASYNC }, + G_DBUS_METHOD_FLAG_ASYNC }, { } }; @@ -1431,7 +1432,8 @@ static void sim_read_cf_indicator(struct ofono_call_forwarding *cf) } } -int ofono_call_forwarding_driver_register(const struct ofono_call_forwarding_driver *d) +int ofono_call_forwarding_driver_register( + const struct ofono_call_forwarding_driver *d) { DBG("driver: %p, name: %s", d, d->name); @@ -1443,7 +1445,8 @@ int ofono_call_forwarding_driver_register(const struct ofono_call_forwarding_dri return 0; } -void ofono_call_forwarding_driver_unregister(const struct ofono_call_forwarding_driver *d) +void ofono_call_forwarding_driver_unregister( + const struct ofono_call_forwarding_driver *d) { DBG("driver: %p, name: %s", d, d->name); @@ -1467,10 +1470,10 @@ static void call_forwarding_remove(struct ofono_atom *atom) g_free(cf); } -struct ofono_call_forwarding *ofono_call_forwarding_create(struct ofono_modem *modem, - unsigned int vendor, - const char *driver, - void *data) +struct ofono_call_forwarding *ofono_call_forwarding_create( + struct ofono_modem *modem, + unsigned int vendor, + const char *driver, void *data) { struct ofono_call_forwarding *cf; GSList *l; @@ -1552,7 +1555,8 @@ void ofono_call_forwarding_remove(struct ofono_call_forwarding *cf) __ofono_atom_free(cf->atom); } -void ofono_call_forwarding_set_data(struct ofono_call_forwarding *cf, void *data) +void ofono_call_forwarding_set_data(struct ofono_call_forwarding *cf, + void *data) { cf->driver_data = data; } -- 1.7.5.4 From oleg.zhurakivskyy at intel.com Mon Feb 6 04:33:55 2012 From: oleg.zhurakivskyy at intel.com (Oleg Zhurakivskyy) Date: Mon, 6 Feb 2012 14:33:55 +0200 Subject: [PATCHv2 2/8] call-forwarding: Minor refactoring of is_cfu_enabled() In-Reply-To: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> References: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> Message-ID: <1328531641-10612-3-git-send-email-oleg.zhurakivskyy@intel.com> This also removes the need for uninitialized_var() macro. --- src/call-forwarding.c | 36 +++++++++++++++++------------------- 1 files changed, 17 insertions(+), 19 deletions(-) diff --git a/src/call-forwarding.c b/src/call-forwarding.c index 731a38a..8b8d5a8 100644 --- a/src/call-forwarding.c +++ b/src/call-forwarding.c @@ -36,14 +36,17 @@ #include "common.h" #include "simutil.h" -#define uninitialized_var(x) x = x - #define CALL_FORWARDING_FLAG_CACHED 0x1 #define CALL_FORWARDING_FLAG_CPHS_CFF 0x2 /* According to 27.007 Spec */ #define DEFAULT_NO_REPLY_TIMEOUT 20 +#define is_cfu_enabled(_cf) \ +({ \ + cf_find_unconditional(_cf) ? TRUE : FALSE; \ +}) + enum call_forwarding_type { CALL_FORWARDING_TYPE_UNCONDITIONAL = 0, CALL_FORWARDING_TYPE_BUSY = 1, @@ -221,8 +224,8 @@ static void sim_cphs_cff_update_cb(int ok, void *data) ofono_info("Failed to update EFcphs-cff"); } -static gboolean is_cfu_enabled(struct ofono_call_forwarding *cf, - struct ofono_call_forwarding_condition **out) +static struct ofono_call_forwarding_condition *cf_find_unconditional( + struct ofono_call_forwarding *cf) { GSList *l = cf->cf_conditions[CALL_FORWARDING_TYPE_UNCONDITIONAL]; struct ofono_call_forwarding_condition *cond; @@ -237,21 +240,16 @@ static gboolean is_cfu_enabled(struct ofono_call_forwarding *cf, if (cond->cls > BEARER_CLASS_VOICE) continue; - if (out) - *out = cond; - - return TRUE; + return cond; } - return FALSE; + return NULL; } static void sim_set_cf_indicator(struct ofono_call_forwarding *cf) { - gboolean cfu_voice; - struct ofono_call_forwarding_condition *uninitialized_var(cond); - - cfu_voice = is_cfu_enabled(cf, &cond); + struct ofono_call_forwarding_condition *cfu_voice = + cf_find_unconditional(cf); if (cf->cfis_record_id) { unsigned char data[16]; @@ -263,15 +261,15 @@ static void sim_set_cf_indicator(struct ofono_call_forwarding *cf) data[0] = 0x01; if (cfu_voice) { - number_len = strlen(cond->phone_number.number); + number_len = strlen(cfu_voice->phone_number.number); /* CFU indicator Status - Voice */ data[1] = 0x01; number_len = (number_len + 1) / 2; data[2] = number_len + 1; - data[3] = cond->phone_number.type; + data[3] = cfu_voice->phone_number.type; - sim_encode_bcd_number(cond->phone_number.number, + sim_encode_bcd_number(cfu_voice->phone_number.number, data + 4); } else { data[1] = 0x00; @@ -317,7 +315,7 @@ static void set_new_cond_list(struct ofono_call_forwarding *cf, if ((cf->flags & CALL_FORWARDING_FLAG_CPHS_CFF) || cf->cfis_record_id > 0) - old_cfu = is_cfu_enabled(cf, NULL); + old_cfu = is_cfu_enabled(cf); else old_cfu = FALSE; @@ -432,7 +430,7 @@ static void set_new_cond_list(struct ofono_call_forwarding *cf, if ((cf->flags & CALL_FORWARDING_FLAG_CPHS_CFF) || cf->cfis_record_id > 0) - new_cfu = is_cfu_enabled(cf, NULL); + new_cfu = is_cfu_enabled(cf); else new_cfu = FALSE; @@ -523,7 +521,7 @@ static DBusMessage *cf_get_properties_reply(DBusMessage *msg, if ((cf->flags & CALL_FORWARDING_FLAG_CPHS_CFF) || cf->cfis_record_id > 0) - status = is_cfu_enabled(cf, NULL); + status = is_cfu_enabled(cf); else status = FALSE; -- 1.7.5.4 From oleg.zhurakivskyy at intel.com Mon Feb 6 04:33:56 2012 From: oleg.zhurakivskyy at intel.com (Oleg Zhurakivskyy) Date: Mon, 6 Feb 2012 14:33:56 +0200 Subject: [PATCHv2 3/8] call-forwarding: Don't set conditional cfs when cfu is active In-Reply-To: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> References: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> Message-ID: <1328531641-10612-4-git-send-email-oleg.zhurakivskyy@intel.com> --- src/call-forwarding.c | 18 ++++++++++++++++++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/src/call-forwarding.c b/src/call-forwarding.c index 8b8d5a8..3f9d816 100644 --- a/src/call-forwarding.c +++ b/src/call-forwarding.c @@ -802,6 +802,13 @@ static DBusMessage *cf_set_property(DBusConnection *conn, DBusMessage *msg, if (strlen(number) > 0 && !valid_phone_number_format(number)) return __ofono_error_invalid_format(msg); + /* + * Don't set conditional cfs when cfu is active + */ + if (type != CALL_FORWARDING_TYPE_UNCONDITIONAL && + number[0] != '\0' && is_cfu_enabled(cf)) + return __ofono_error_not_available(msg); + if (number[0] != '\0') string_to_phone_number(number, &ph); @@ -1159,6 +1166,17 @@ static gboolean cf_ss_control(int type, const char *sc, return TRUE; } + /* + * Don't set conditional cfs when cfu is active + */ + if (type == SS_CONTROL_TYPE_REGISTRATION && + cf_type != CALL_FORWARDING_TYPE_UNCONDITIONAL && + sia[0] != '\0' && is_cfu_enabled(cf)) { + g_dbus_send_message(conn, __ofono_error_not_available(msg)); + + return TRUE; + } + cf->ss_req = g_try_new0(struct cf_ss_request, 1); if (cf->ss_req == NULL) { -- 1.7.5.4 From oleg.zhurakivskyy at intel.com Mon Feb 6 04:33:57 2012 From: oleg.zhurakivskyy at intel.com (Oleg Zhurakivskyy) Date: Mon, 6 Feb 2012 14:33:57 +0200 Subject: [PATCHv2 4/8] call-forwarding: Don't report conditional cfs when cfu is active In-Reply-To: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> References: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> Message-ID: <1328531641-10612-5-git-send-email-oleg.zhurakivskyy@intel.com> --- src/call-forwarding.c | 20 +++++++++++++++++--- 1 files changed, 17 insertions(+), 3 deletions(-) diff --git a/src/call-forwarding.c b/src/call-forwarding.c index 3f9d816..f9bee6b 100644 --- a/src/call-forwarding.c +++ b/src/call-forwarding.c @@ -503,6 +503,8 @@ static DBusMessage *cf_get_properties_reply(DBusMessage *msg, DBusMessageIter dict; int i; dbus_bool_t status; + gboolean cfu_enabled; + GSList *cf_list; reply = dbus_message_new_method_return(msg); if (reply == NULL) @@ -514,14 +516,26 @@ static DBusMessage *cf_get_properties_reply(DBusMessage *msg, OFONO_PROPERTIES_ARRAY_SIGNATURE, &dict); - for (i = 0; i < 4; i++) - property_append_cf_conditions(&dict, cf->cf_conditions[i], + cfu_enabled = is_cfu_enabled(cf); + + for (i = 0; i < 4; i++) { + + /* + * Report conditional cfs as empty when CFU is active + */ + if (cfu_enabled && (i != CALL_FORWARDING_TYPE_UNCONDITIONAL)) + cf_list = NULL; + else + cf_list = cf->cf_conditions[i]; + + property_append_cf_conditions(&dict, cf_list, BEARER_CLASS_VOICE, cf_type_lut[i]); + } if ((cf->flags & CALL_FORWARDING_FLAG_CPHS_CFF) || cf->cfis_record_id > 0) - status = is_cfu_enabled(cf); + status = cfu_enabled; else status = FALSE; -- 1.7.5.4 From oleg.zhurakivskyy at intel.com Mon Feb 6 04:33:58 2012 From: oleg.zhurakivskyy at intel.com (Oleg Zhurakivskyy) Date: Mon, 6 Feb 2012 14:33:58 +0200 Subject: [PATCHv2 5/8] call-forwarding: Emit signals to mask/unmask conditional cfs In-Reply-To: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> References: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> Message-ID: <1328531641-10612-6-git-send-email-oleg.zhurakivskyy@intel.com> Emit signals to mask/unmask conditional cfs on cfu activation/deactivation. --- src/call-forwarding.c | 30 ++++++++++++++++++++++++++++++ 1 files changed, 30 insertions(+), 0 deletions(-) diff --git a/src/call-forwarding.c b/src/call-forwarding.c index f9bee6b..7b086e0 100644 --- a/src/call-forwarding.c +++ b/src/call-forwarding.c @@ -436,6 +436,36 @@ static void set_new_cond_list(struct ofono_call_forwarding *cf, if (new_cfu != old_cfu) { ofono_bool_t status = new_cfu; + int i; + + /* + * Emit signals to mask/unmask conditional cfs on cfu change + */ + for (i = 0; i < 4; i++) { + if (i == CALL_FORWARDING_TYPE_UNCONDITIONAL) + continue; + + l = g_slist_find_custom(cf->cf_conditions[i], + GINT_TO_POINTER(BEARER_CLASS_VOICE), + cf_condition_find_with_cls); + + if (l == NULL) + continue; + + if (new_cfu) + number = ""; + else { + lc = l->data; + + number = phone_number_to_string( + &lc->phone_number); + } + + ofono_dbus_signal_property_changed(conn, path, + OFONO_CALL_FORWARDING_INTERFACE, + cf_type_lut[i], + DBUS_TYPE_STRING, &number); + } ofono_dbus_signal_property_changed(conn, path, OFONO_CALL_FORWARDING_INTERFACE, -- 1.7.5.4 From oleg.zhurakivskyy at intel.com Mon Feb 6 04:33:59 2012 From: oleg.zhurakivskyy at intel.com (Oleg Zhurakivskyy) Date: Mon, 6 Feb 2012 14:33:59 +0200 Subject: [PATCHv2 6/8] call-forwarding: Don't run conditional queries if cfu is active In-Reply-To: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> References: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> Message-ID: <1328531641-10612-7-git-send-email-oleg.zhurakivskyy@intel.com> --- src/call-forwarding.c | 18 +++++++++++------- 1 files changed, 11 insertions(+), 7 deletions(-) diff --git a/src/call-forwarding.c b/src/call-forwarding.c index 7b086e0..2813005 100644 --- a/src/call-forwarding.c +++ b/src/call-forwarding.c @@ -584,20 +584,24 @@ static void get_query_cf_callback(const struct ofono_error *error, int total, struct ofono_call_forwarding *cf = data; if (error->type == OFONO_ERROR_TYPE_NO_ERROR) { - GSList *l; - l = cf_cond_list_create(total, list); + GSList *l = cf_cond_list_create(total, list); + set_new_cond_list(cf, cf->query_next, l); DBG("%s conditions:", cf_type_lut[cf->query_next]); + cf_cond_list_print(l); + } - if (cf->query_next == CALL_FORWARDING_TYPE_NOT_REACHABLE) + if ((is_cfu_enabled(cf) && + cf->query_next == CALL_FORWARDING_TYPE_UNCONDITIONAL) || + cf->query_next == CALL_FORWARDING_TYPE_NOT_REACHABLE) { + + if (error->type == OFONO_ERROR_TYPE_NO_ERROR) cf->flags |= CALL_FORWARDING_FLAG_CACHED; - } - if (cf->query_next == CALL_FORWARDING_TYPE_NOT_REACHABLE) { - DBusMessage *reply = cf_get_properties_reply(cf->pending, cf); - __ofono_dbus_pending_reply(&cf->pending, reply); + __ofono_dbus_pending_reply(&cf->pending, + cf_get_properties_reply(cf->pending, cf)); return; } -- 1.7.5.4 From oleg.zhurakivskyy at intel.com Mon Feb 6 04:34:00 2012 From: oleg.zhurakivskyy at intel.com (Oleg Zhurakivskyy) Date: Mon, 6 Feb 2012 14:34:00 +0200 Subject: [PATCHv2 7/8] call-forwarding: Clear the conditional cache flag In-Reply-To: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> References: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> Message-ID: <1328531641-10612-8-git-send-email-oleg.zhurakivskyy@intel.com> If there is an successful attempt to deactivate conditional cf while cfu is active, the conditional cache flag is cleared. --- src/call-forwarding.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/src/call-forwarding.c b/src/call-forwarding.c index 2813005..a38a743 100644 --- a/src/call-forwarding.c +++ b/src/call-forwarding.c @@ -722,6 +722,14 @@ static void set_query_cf_callback(const struct ofono_error *error, int total, DBG("%s conditions:", cf_type_lut[cf->query_next]); cf_cond_list_print(l); + /* + * If there is an successful attempt to deactivate conditional cf + * while cfu is active, the conditional cache flag is cleared. + */ + if (cf->query_next != CALL_FORWARDING_TYPE_UNCONDITIONAL && + is_cfu_enabled(cf)) + cf->flags &= ~CALL_FORWARDING_FLAG_CACHED; + if (cf->query_next != cf->query_end) { cf->query_next++; set_query_next_cf_cond(cf); -- 1.7.5.4 From oleg.zhurakivskyy at intel.com Mon Feb 6 04:34:01 2012 From: oleg.zhurakivskyy at intel.com (Oleg Zhurakivskyy) Date: Mon, 6 Feb 2012 14:34:01 +0200 Subject: [PATCHv2 8/8] TODO: Remove completed call forwarding state task In-Reply-To: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> References: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> Message-ID: <1328531641-10612-9-git-send-email-oleg.zhurakivskyy@intel.com> --- TODO | 17 ----------------- 1 files changed, 0 insertions(+), 17 deletions(-) diff --git a/TODO b/TODO index 1fef651..9948117 100644 --- a/TODO +++ b/TODO @@ -213,23 +213,6 @@ Supplementary Services Priority: Low Complexity: C8 -- Call forwarding state handling change - - At the moment call forwarding states are not always correct. Any active - conditional call forwarding should become quiescent while unconditional call - forwarding is activate. If call forwarding unconditional is subsequently - deactivated, all the quiescent forwardings should become operative again. - I.e. No conditional call forwarding string should be returned while - unconditional call forwarding is active even if they exist. - - If there is an successful attempt to activate/deactivate conditional call - forwarding while unconditional call forwarding is active the conditional cache - flag should cleared. - - Priority: High - Complexity: C1 - Owner: Nicolas Bertrand - Voicecall ========= -- 1.7.5.4 From nicolas.bertrand at linux.intel.com Tue Feb 7 09:34:17 2012 From: nicolas.bertrand at linux.intel.com (nicolas.bertrand) Date: Tue, 07 Feb 2012 18:34:17 +0100 Subject: setup ofono for telit h910 on embedded system In-Reply-To: References: Message-ID: <4F316099.8090005@linux.intel.com> Hello Jan, On 02/03/2012 03:34 PM, Jan Pohanka wrote: > Hello, > > I'm working on embedded system with dm365 processor (arm926ej-s) and I > want to use ofono with a Telit h910 modem connected by usb. The module > works, I can make a calls using AT commands on /dev/ttyACM3 (or ttyS1), > but I'm not able to register it with ofono. > > I have added following line to /lib/udev/rules.d/ofono.rules > KERNEL=="ttyACM3", ENV{OFONO_DRIVER}="telit" (I have tried atgen also) > > After enabling the modem I'm getting following debug messages... > ofonod[133]: plugins/udevng.c:udev_start() > ofonod[133]: plugins/udevng.c:enumerate_devices() > ofonod[133]: plugins/udevng.c:check_usb_device() MOSCHIP usb-ethernet > driver [9710:7830] > usb 1-1.3: new high speed USB device using musb_hdrc and address 5 > usb 1-1.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an > invalid bInterval 255, changing t > o 11 > usb 1-1.3: New USB device found, idVendor=058b, idProduct=0041 > usb 1-1.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0 > usb 1-1.3: configuration #1 chosen from 1 choice > usb 1-1.3: USB disconnect, address 5 > usb 1-1.3: new high speed USB device using musb_hdrc and address 6 > usb 1-1.3: New USB device found, idVendor=1bc7, idProduct=0021 > usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > usb 1-1.3: Product: Telit Wireless Module > usb 1-1.3: Manufacturer: Telit wireless solutions > usb 1-1.3: SerialNumber: 357164040028220 > usb 1-1.3: configuration #1 chosen from 1 choice > cdc_acm 1-1.3:1.0: This device cannot do calls on its own. It is not a > modem. > cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device > cdc_acm 1-1.3:1.2: This device cannot do calls on its own. It is not a > modem. > cdc_acm 1-1.3:1.2: ttyACM1: USB ACM device > cdc_acm 1-1.3:1.4: This device cannot do calls on its own. It is not a > modem. > cdc_acm 1-1.3:1.4: ttyACM2: USB ACM device > cdc_acm 1-1.3:1.6: This device cannot do calls on its own. It is not a > modem. > cdc_acm 1-1.3:1.6: ttyACM3: USB ACM device > cdc_acm 1-1.3:1.8: This device cannot do calls on its own. It is not a > modem. > cdc_acm 1-1.3:1.8: ttyACM4: USB ACM device > cdc_acm 1-1.3:1.10: This device cannot do calls on its own. It is not a > modem. > cdc_acm 1-1.3:1.10: ttyACM5: USB ACM device > cdc_acm 1-1.3:1.12: This device cannot do calls on its own. It is not a > modem. > cdc_acm 1-1.3:1.12: ttyACM6: USB ACM device > ofonod[133]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] > ofonod[133]: plugins/udev.c:udev_event() subsystem tty add > ofonod[133]: plugins/udev.c:udev_event() subsystem tty finished > ofonod[133]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] > ofonod[133]: plugins/udev.c:udev_event() subsystem tty add > ofonod[133]: plugins/udev.c:udev_event() subsystem tty finished > ofonod[133]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] > ofonod[133]: plugins/udev.c:udev_event() subsystem tty add > ofonod[133]: plugins/udev.c:udev_event() subsystem tty finished > ofonod[133]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] > ofonod[133]: plugins/udev.c:udev_event() subsystem tty add > ofonod[133]: src/modem.c:ofono_modem_create() name: (null), type: atgen > ofonod[133]: src/modem.c:set_modem_property() modem 0xeebb0 property Path > ofonod[133]: plugins/udev.c:add_modem() > /devices/platform/musb_hdrc/usb1/1-1/1-1.3/1-1.3:1.6/tty/ttyACM3 (atgen) > ofonod[133]: plugins/udev.c:udev_event() subsystem tty finished > ofonod[133]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] > ofonod[133]: plugins/udev.c:udev_event() subsystem tty add > ofonod[133]: plugins/udev.c:udev_event() subsystem tty finished > ofonod[133]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] > ofonod[133]: plugins/udev.c:udev_event() subsystem tty add > ofonod[133]: plugins/udev.c:udev_event() subsystem tty finished > ofonod[133]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] > ofonod[133]: plugins/udev.c:udev_event() subsystem tty add > ofonod[133]: plugins/udev.c:udev_event() subsystem tty finished > ofonod[133]: plugins/udevng.c:check_modem_list() > > > Unfortunately list-modems command still return nothing. > Could please anybody here give me some advice how to solve the problem? > > best regards > Jan > > What is your version of ofono? The log is not complete and so we can't see this information. Some features about telit devices have been implemented recently, using a ofono version >= 1.1 should be better and then you won't need ofono.rules anymore , it's a deprecated file. -- regards, Nico From xhpohanka at gmail.com Tue Feb 7 22:38:15 2012 From: xhpohanka at gmail.com (Jan Pohanka) Date: Wed, 08 Feb 2012 07:38:15 +0100 Subject: setup ofono for telit h910 on embedded system In-Reply-To: <4F316099.8090005@linux.intel.com> References: <4F316099.8090005@linux.intel.com> Message-ID: Hello Nicolas, thank you for the response. Please see reactions below... Dne Tue, 07 Feb 2012 18:34:17 +0100 nicolas.bertrand napsal(a): > > What is your version of ofono? > I'm using the latest release ofono-1.3. > The log is not complete and so we can't see this information. full log is at the end of the message > > Some features about telit devices have been implemented recently, using > a ofono version >= 1.1 should be better and then you won't need > ofono.rules anymore , it's a deprecated file. > Unfortunately I have not found much documentation how to properly register a modem to ofono. Just these two links (http://wiki.maemo.org/User:Jebba/Ofono, http://ofono.org/wiki/how-enable-modem-ofono). Both suggests ofono.rules file and the first one also /etc/ofono/modem.conf file. Which one should be used now, please? Even if the Telit h910 is not fully supported, it uses some standard AT commands so I think I should be able to control it at least on basic level using ofono. Am I right? Here is the log from the ofonod -nd ofonod[321]: oFono version 1.3 ofonod[321]: src/plugin.c:__ofono_plugin_init() ofonod[321]: plugins/push-notification.c:push_notification_init() ofonod[321]: plugins/smart-messaging.c:smart_messaging_init() ofonod[321]: src/cdma-provision.c:ofono_cdma_provision_driver_register() driver: 0xdc418 name: CD MA provisioning ofonod[321]: src/gprs-provision.c:ofono_gprs_provision_driver_register() driver: 0xdc3ec name: Pr ovisioning ofonod[321]: plugins/connman.c:connman_init() ofonod[321]: src/private-network.c:ofono_private_network_driver_register() driver: 0xdc3c0, name: ConnMan Private Network ofonod[321]: plugins/dun_gw.c:dun_gw_init() ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdc2e0, name: hfp ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdc288, name: sap ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdc214, name: telit ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdc1a8, name: sim900 ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdc160, name: samsung ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdc118, name: speedupcdma ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdc0d0, name: speedup ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdc088, name: alcatel ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdc040, name: linktop ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbff8, name: nokiacdma ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbfb0, name: nokia ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbf68, name: tc65 ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbee0, name: ste ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbe90, name: ifx ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbe48, name: palmpre ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbdf8, name: novatel ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbdb0, name: sierra ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbd38, name: huawei ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbcf0, name: zte ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbc90, name: hso ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbc40, name: mbm ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbbf0, name: calypso ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbba8, name: wavecom ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbb60, name: gobi ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbb18, name: g1 ofonod[321]: src/cdma-voicecall.c:ofono_cdma_voicecall_driver_register() driver: 0xdbac0, name: c dmamodem ofonod[321]: src/modem.c:ofono_devinfo_driver_register() driver: 0xdbae8, name: cdmamodem ofonod[321]: src/cdma-connman.c:ofono_cdma_connman_driver_register() driver: 0xdbb04, name: cdmam odem ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdba28, name: phonesim ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdba58, name: localhfp ofonod[321]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0xdba14, name: phonesim ofonod[321]: src/ctm.c:ofono_ctm_driver_register() driver: 0xdba00, name: phonesim ofonod[321]: plugins/phonesim.c:parse_config() filename /etc/ofono/phonesim.conf ofonod[321]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0xdb91c, name: hfpmodem ofonod[321]: src/modem.c:ofono_devinfo_driver_register() driver: 0xdb9c0, name: hfpmodem ofonod[321]: src/network.c:ofono_netreg_driver_register() driver: 0xdb974, name: hfpmodem ofonod[321]: src/call-volume.c:ofono_call_volume_driver_register() driver: 0xdb9a8, name: hfpmode m ofonod[321]: src/handsfree.c:ofono_handsfree_driver_register() driver: 0xdb9ec, name: hfpmodem ofonod[321]: src/network.c:ofono_netreg_driver_register() driver: 0xdb89c, name: dunmodem ofonod[321]: src/gprs.c:ofono_gprs_driver_register() driver: 0xdb8c0, name: dunmodem ofonod[321]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0xdb7d8, name: stemodem ofonod[321]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0xdb860, name: stemodem ofonod[321]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0xdb828, name: s temodem ofonod[321]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0xdb6c8, name: ifxmodem ofonod[321]: src/audio-settings.c:ofono_audio_settings_driver_register() driver: 0xdb718, name: i fxmodem ofonod[321]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0xdb72c, name: i fxmodem ofonod[321]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0xdb760, name: ifxmodem ofonod[321]: src/stk.c:ofono_stk_driver_register() driver: 0xdb784, name: ifxmodem ofonod[321]: src/ctm.c:ofono_ctm_driver_register() driver: 0xdb7a4, name: ifxmodem ofonod[321]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0xdb660, name: hsomodem ofonod[321]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0xdb67c, name: h somodem ofonod[321]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0xdb5e4, name: mbmmodem ofonod[321]: src/stk.c:ofono_stk_driver_register() driver: 0xdb600, name: mbmmodem ofonod[321]: src/location-reporting.c:ofono_location_reporting_driver_register() driver: 0xdb620, name: mbmmodem ofonod[321]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0xdb54c, name: calypsomode m ofonod[321]: src/stk.c:ofono_stk_driver_register() driver: 0xdb59c, name: calypsomodem ofonod[321]: src/ussd.c:ofono_ussd_driver_register() driver: 0xdb45c, name: huaweimodem ofonod[321]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0xdb470, name: huaweimodem ofonod[321]: src/audio-settings.c:ofono_audio_settings_driver_register() driver: 0xdb4c0, name: h uaweimodem ofonod[321]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0xdb4f0, name: h uaweimodem ofonod[321]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0xdb4d4, name: huaweimodem ofonod[321]: src/cdma-netreg.c:ofono_cdma_netreg_driver_register() driver: 0xdb51c, name: huaweim odem ofonod[321]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0xdb410, name: n wmodem ofonod[321]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0xdb290, name: atmodem ofonod[321]: src/modem.c:ofono_devinfo_driver_register() driver: 0xdb328, name: atmodem ofonod[321]: src/call-barring.c:ofono_call_barring_driver_register() driver: 0xdb2e0, name: atmod em ofonod[321]: src/call-forwarding.c:ofono_call_forwarding_driver_register() driver: 0xdb0a0, name: atmodem ofonod[321]: src/call-meter.c:ofono_call_meter_driver_register() driver: 0xdb0e0, name: atmodem ofonod[321]: src/call-settings.c:ofono_call_settings_driver_register() driver: 0xdafec, name: atm odem ofonod[321]: src/phonebook.c:ofono_phonebook_driver_register() driver: 0xdb310, name: atmodem ofonod[321]: src/ussd.c:ofono_ussd_driver_register() driver: 0xdb26c, name: atmodem ofonod[321]: src/sms.c:ofono_sms_driver_register() driver: 0xdb05c, name: atmodem ofonod[321]: src/sim.c:ofono_sim_driver_register() driver: 0xdb1ac, name: atmodem ofonod[321]: src/sim.c:ofono_sim_driver_register() driver: 0xdb1f4, name: atmodem-noef ofonod[321]: src/stk.c:ofono_stk_driver_register() driver: 0xdb244, name: atmodem ofonod[321]: src/network.c:ofono_netreg_driver_register() driver: 0xdb13c, name: atmodem ofonod[321]: src/cbs.c:ofono_cbs_driver_register() driver: 0xdb084, name: atmodem ofonod[321]: src/call-volume.c:ofono_call_volume_driver_register() driver: 0xdb354, name: atmodem ofonod[321]: src/gprs.c:ofono_gprs_driver_register() driver: 0xdb384, name: atmodem ofonod[321]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0xdb398, name: atmodem ofonod[321]: src/sim-auth.c:ofono_sim_auth_driver_register() driver: 0xdb3b4, name: atmodem ofonod[321]: src/gnss.c:ofono_gnss_driver_register() driver: 0xdb3d4, name: atmodem ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdadd0, name: u8500 ofonod[321]: src/modem.c:ofono_devinfo_driver_register() driver: 0xdadb4, name: u8500 ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdad6c, name: n900 ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdad24, name: isiusb ofonod[321]: src/modem.c:ofono_devinfo_driver_register() driver: 0xdaadc, name: isimodem ofonod[321]: src/phonebook.c:ofono_phonebook_driver_register() driver: 0xdaacc, name: isimodem ofonod[321]: src/network.c:ofono_netreg_driver_register() driver: 0xdaaf8, name: isimodem ofonod[321]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0xdab1c, name: isimodem ofonod[321]: src/sms.c:ofono_sms_driver_register() driver: 0xdab64, name: isimodem ofonod[321]: src/cbs.c:ofono_cbs_driver_register() driver: 0xdab84, name: isimodem ofonod[321]: src/sim.c:ofono_sim_driver_register() driver: 0xdab98, name: isimodem ofonod[321]: src/ussd.c:ofono_ussd_driver_register() driver: 0xdabe0, name: isimodem ofonod[321]: src/call-forwarding.c:ofono_call_forwarding_driver_register() driver: 0xdabf4, name: isimodem ofonod[321]: src/call-settings.c:ofono_call_settings_driver_register() driver: 0xdac14, name: isi modem ofonod[321]: src/call-barring.c:ofono_call_barring_driver_register() driver: 0xdac44, name: isimo dem ofonod[321]: src/call-meter.c:ofono_call_meter_driver_register() driver: 0xdac5c, name: isimodem ofonod[321]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0xdac84, name: i simodem ofonod[321]: src/gprs.c:ofono_gprs_driver_register() driver: 0xdaca8, name: isimodem ofonod[321]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0xdacbc, name: isimodem ofonod[321]: src/audio-settings.c:ofono_audio_settings_driver_register() driver: 0xdacd0, name: i simodem ofonod[321]: src/sim.c:ofono_sim_driver_register() driver: 0xdacdc, name: wgmodem2.5 ofonod[321]: plugins/udevng.c:udev_start() ofonod[321]: plugins/udevng.c:enumerate_devices() ofonod[321]: plugins/udevng.c:check_usb_device() MOSCHIP usb-ethernet driver [9710:7830] ofonod[321]: plugins/bluetooth.c:manager_properties_cb() ofonod[321]: plugins/bluetooth.c:parse_adapters() ofonod[321]: plugins/bluetooth.c:parse_adapters() Calling GetProperties on /org/bluez/224/hci0 ofonod[321]: plugins/bluetooth.c:adapter_properties_cb() ofonod[321]: plugins/bluetooth.c:parse_devices() ofonod[321]: plugins/bluetooth.c:adapter_properties_cb() Adapter Address: 00:0C:76:D3:B9:3F, Path : /org/bluez/224/hci0 ofonod[321]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[321]: plugins/udev.c:udev_event() subsystem tty add ofonod[321]: plugins/udev.c:udev_event() subsystem tty finished ofonod[321]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[321]: plugins/udev.c:udev_event() subsystem tty add ofonod[321]: plugins/udev.c:udev_event() subsystem tty finished ofonod[321]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[321]: plugins/udev.c:udev_event() subsystem tty add ofonod[321]: plugins/udev.c:udev_event() subsystem tty finished ofonod[321]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[321]: plugins/udev.c:udev_event() subsystem tty add ofonod[321]: plugins/udev.c:udev_event() subsystem tty finished ofonod[321]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[321]: plugins/udev.c:udev_event() subsystem tty add ofonod[321]: plugins/udev.c:udev_event() subsystem tty finished ofonod[321]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[321]: plugins/udev.c:udev_event() subsystem tty add ofonod[321]: plugins/udev.c:udev_event() subsystem tty finished ofonod[321]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[321]: plugins/udev.c:udev_event() subsystem tty add ofonod[321]: src/modem.c:ofono_modem_create() name: (null), type: telit ofonod[321]: src/modem.c:set_modem_property() modem 0xeab98 property Path ofonod[321]: plugins/udev.c:add_modem() /devices/platform/musb_hdrc/usb1/1-1/1-1.3/1-1.3:1.6/tty/ ttyACM3 (telit) ofonod[321]: plugins/udev.c:udev_event() subsystem tty finished ofonod[321]: plugins/udevng.c:check_modem_list() root at jc-dev:~# ./test/list-modems root at jc-dev:~# ./test/enable-modem Traceback (most recent call last): File "./test/enable-modem", line 14, in path = modems[0][0] IndexError: list index out of range best regards Jan -- Tato zpr?va byla vytvo?ena p?evratn?m po?tovn?m klientem Opery: http://www.opera.com/mail/ From frederic.danis at linux.intel.com Thu Feb 9 01:12:34 2012 From: frederic.danis at linux.intel.com (=?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Danis?=) Date: Thu, 9 Feb 2012 10:12:34 +0100 Subject: [PATCH] voicecall: Fix emulator AT+CHUP for HFP Message-ID: <1328778754-5108-1-git-send-email-frederic.danis@linux.intel.com> AT+CHUP should be able to hang-up active or incoming calls --- src/voicecall.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/voicecall.c b/src/voicecall.c index 094f41d..e224d3a 100644 --- a/src/voicecall.c +++ b/src/voicecall.c @@ -2931,7 +2931,8 @@ static void emulator_chup_cb(struct ofono_emulator *em, goto done; } - if (voicecalls_have_active(vc) == FALSE) + if (voicecalls_have_active(vc) == FALSE && + voicecalls_have_incoming(vc) == FALSE) goto fail; vc->pending_em = em; -- 1.7.1 From nicolas.bertrand at linux.intel.com Thu Feb 9 02:28:44 2012 From: nicolas.bertrand at linux.intel.com (nicolas.bertrand) Date: Thu, 09 Feb 2012 11:28:44 +0100 Subject: setup ofono for telit h910 on embedded system In-Reply-To: References: <4F316099.8090005@linux.intel.com> Message-ID: <4F339FDC.8030700@linux.intel.com> Hello jan, On 02/08/2012 07:38 AM, Jan Pohanka wrote: > Hello Nicolas, > > thank you for the response. Please see reactions below... > > > Dne Tue, 07 Feb 2012 18:34:17 +0100 nicolas.bertrand > napsal(a): > > >> >> What is your version of ofono? >> > I'm using the latest release ofono-1.3. > >> The log is not complete and so we can't see this information. > > full log is at the end of the message > >> >> Some features about telit devices have been implemented recently, >> using a ofono version >= 1.1 should be better and then you won't need >> ofono.rules anymore , it's a deprecated file. >> > Unfortunately I have not found much documentation how to properly > register a modem to ofono. Just these two links > (http://wiki.maemo.org/User:Jebba/Ofono, > http://ofono.org/wiki/how-enable-modem-ofono). Both suggests ofono.rules > file and the first one also /etc/ofono/modem.conf file. Which one should > be used now, please? > Even if the Telit h910 is not fully supported, it uses some standard AT > commands so I think I should be able to control it at least on basic > level using ofono. Am I right? > > Here is the log from the ofonod -nd > > ofonod[321]: oFono version 1.3 > ofonod[321]: src/plugin.c:__ofono_plugin_init() > ofonod[321]: plugins/push-notification.c:push_notification_init() > ofonod[321]: plugins/smart-messaging.c:smart_messaging_init() > ofonod[321]: src/cdma-provision.c:ofono_cdma_provision_driver_register() > driver: 0xdc418 name: CD > MA provisioning > ofonod[321]: src/gprs-provision.c:ofono_gprs_provision_driver_register() > driver: 0xdc3ec name: Pr > ovisioning > ofonod[321]: plugins/connman.c:connman_init() > ofonod[321]: > src/private-network.c:ofono_private_network_driver_register() driver: > 0xdc3c0, name: > ConnMan Private Network > ofonod[321]: plugins/dun_gw.c:dun_gw_init() > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdc2e0, > name: hfp > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdc288, > name: sap > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdc214, > name: telit > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdc1a8, > name: sim900 > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdc160, > name: samsung > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdc118, > name: speedupcdma > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdc0d0, > name: speedup > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdc088, > name: alcatel > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdc040, > name: linktop > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbff8, > name: nokiacdma > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbfb0, > name: nokia > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbf68, > name: tc65 > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbee0, > name: ste > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbe90, > name: ifx > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbe48, > name: palmpre > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbdf8, > name: novatel > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbdb0, > name: sierra > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbd38, > name: huawei > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbcf0, > name: zte > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbc90, > name: hso > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbc40, > name: mbm > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbbf0, > name: calypso > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbba8, > name: wavecom > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbb60, > name: gobi > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdbb18, > name: g1 > ofonod[321]: src/cdma-voicecall.c:ofono_cdma_voicecall_driver_register() > driver: 0xdbac0, name: c > dmamodem > ofonod[321]: src/modem.c:ofono_devinfo_driver_register() driver: > 0xdbae8, name: cdmamodem > ofonod[321]: src/cdma-connman.c:ofono_cdma_connman_driver_register() > driver: 0xdbb04, name: cdmam > odem > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdba28, > name: phonesim > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdba58, > name: localhfp > ofonod[321]: src/gprs.c:ofono_gprs_context_driver_register() driver: > 0xdba14, name: phonesim > ofonod[321]: src/ctm.c:ofono_ctm_driver_register() driver: 0xdba00, > name: phonesim > ofonod[321]: plugins/phonesim.c:parse_config() filename > /etc/ofono/phonesim.conf > ofonod[321]: src/voicecall.c:ofono_voicecall_driver_register() driver: > 0xdb91c, name: hfpmodem > ofonod[321]: src/modem.c:ofono_devinfo_driver_register() driver: > 0xdb9c0, name: hfpmodem > ofonod[321]: src/network.c:ofono_netreg_driver_register() driver: > 0xdb974, name: hfpmodem > ofonod[321]: src/call-volume.c:ofono_call_volume_driver_register() > driver: 0xdb9a8, name: hfpmode > m > ofonod[321]: src/handsfree.c:ofono_handsfree_driver_register() driver: > 0xdb9ec, name: hfpmodem > ofonod[321]: src/network.c:ofono_netreg_driver_register() driver: > 0xdb89c, name: dunmodem > ofonod[321]: src/gprs.c:ofono_gprs_driver_register() driver: 0xdb8c0, > name: dunmodem > ofonod[321]: src/voicecall.c:ofono_voicecall_driver_register() driver: > 0xdb7d8, name: stemodem > ofonod[321]: src/gprs.c:ofono_gprs_context_driver_register() driver: > 0xdb860, name: stemodem > ofonod[321]: src/radio-settings.c:ofono_radio_settings_driver_register() > driver: 0xdb828, name: s > temodem > ofonod[321]: src/voicecall.c:ofono_voicecall_driver_register() driver: > 0xdb6c8, name: ifxmodem > ofonod[321]: src/audio-settings.c:ofono_audio_settings_driver_register() > driver: 0xdb718, name: i > fxmodem > ofonod[321]: src/radio-settings.c:ofono_radio_settings_driver_register() > driver: 0xdb72c, name: i > fxmodem > ofonod[321]: src/gprs.c:ofono_gprs_context_driver_register() driver: > 0xdb760, name: ifxmodem > ofonod[321]: src/stk.c:ofono_stk_driver_register() driver: 0xdb784, > name: ifxmodem > ofonod[321]: src/ctm.c:ofono_ctm_driver_register() driver: 0xdb7a4, > name: ifxmodem > ofonod[321]: src/gprs.c:ofono_gprs_context_driver_register() driver: > 0xdb660, name: hsomodem > ofonod[321]: src/radio-settings.c:ofono_radio_settings_driver_register() > driver: 0xdb67c, name: h > somodem > ofonod[321]: src/gprs.c:ofono_gprs_context_driver_register() driver: > 0xdb5e4, name: mbmmodem > ofonod[321]: src/stk.c:ofono_stk_driver_register() driver: 0xdb600, > name: mbmmodem > ofonod[321]: > src/location-reporting.c:ofono_location_reporting_driver_register() > driver: 0xdb620, > name: mbmmodem > ofonod[321]: src/voicecall.c:ofono_voicecall_driver_register() driver: > 0xdb54c, name: calypsomode > m > ofonod[321]: src/stk.c:ofono_stk_driver_register() driver: 0xdb59c, > name: calypsomodem > ofonod[321]: src/ussd.c:ofono_ussd_driver_register() driver: 0xdb45c, > name: huaweimodem > ofonod[321]: src/voicecall.c:ofono_voicecall_driver_register() driver: > 0xdb470, name: huaweimodem > ofonod[321]: src/audio-settings.c:ofono_audio_settings_driver_register() > driver: 0xdb4c0, name: h > uaweimodem > ofonod[321]: src/radio-settings.c:ofono_radio_settings_driver_register() > driver: 0xdb4f0, name: h > uaweimodem > ofonod[321]: src/gprs.c:ofono_gprs_context_driver_register() driver: > 0xdb4d4, name: huaweimodem > ofonod[321]: src/cdma-netreg.c:ofono_cdma_netreg_driver_register() > driver: 0xdb51c, name: huaweim > odem > ofonod[321]: src/radio-settings.c:ofono_radio_settings_driver_register() > driver: 0xdb410, name: n > wmodem > ofonod[321]: src/voicecall.c:ofono_voicecall_driver_register() driver: > 0xdb290, name: atmodem > ofonod[321]: src/modem.c:ofono_devinfo_driver_register() driver: > 0xdb328, name: atmodem > ofonod[321]: src/call-barring.c:ofono_call_barring_driver_register() > driver: 0xdb2e0, name: atmod > em > ofonod[321]: > src/call-forwarding.c:ofono_call_forwarding_driver_register() driver: > 0xdb0a0, name: > atmodem > ofonod[321]: src/call-meter.c:ofono_call_meter_driver_register() driver: > 0xdb0e0, name: atmodem > ofonod[321]: src/call-settings.c:ofono_call_settings_driver_register() > driver: 0xdafec, name: atm > odem > ofonod[321]: src/phonebook.c:ofono_phonebook_driver_register() driver: > 0xdb310, name: atmodem > ofonod[321]: src/ussd.c:ofono_ussd_driver_register() driver: 0xdb26c, > name: atmodem > ofonod[321]: src/sms.c:ofono_sms_driver_register() driver: 0xdb05c, > name: atmodem > ofonod[321]: src/sim.c:ofono_sim_driver_register() driver: 0xdb1ac, > name: atmodem > ofonod[321]: src/sim.c:ofono_sim_driver_register() driver: 0xdb1f4, > name: atmodem-noef > ofonod[321]: src/stk.c:ofono_stk_driver_register() driver: 0xdb244, > name: atmodem > ofonod[321]: src/network.c:ofono_netreg_driver_register() driver: > 0xdb13c, name: atmodem > ofonod[321]: src/cbs.c:ofono_cbs_driver_register() driver: 0xdb084, > name: atmodem > ofonod[321]: src/call-volume.c:ofono_call_volume_driver_register() > driver: 0xdb354, name: atmodem > ofonod[321]: src/gprs.c:ofono_gprs_driver_register() driver: 0xdb384, > name: atmodem > ofonod[321]: src/gprs.c:ofono_gprs_context_driver_register() driver: > 0xdb398, name: atmodem > ofonod[321]: src/sim-auth.c:ofono_sim_auth_driver_register() driver: > 0xdb3b4, name: atmodem > ofonod[321]: src/gnss.c:ofono_gnss_driver_register() driver: 0xdb3d4, > name: atmodem > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdadd0, > name: u8500 > ofonod[321]: src/modem.c:ofono_devinfo_driver_register() driver: > 0xdadb4, name: u8500 > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdad6c, > name: n900 > ofonod[321]: src/modem.c:ofono_modem_driver_register() driver: 0xdad24, > name: isiusb > ofonod[321]: src/modem.c:ofono_devinfo_driver_register() driver: > 0xdaadc, name: isimodem > ofonod[321]: src/phonebook.c:ofono_phonebook_driver_register() driver: > 0xdaacc, name: isimodem > ofonod[321]: src/network.c:ofono_netreg_driver_register() driver: > 0xdaaf8, name: isimodem > ofonod[321]: src/voicecall.c:ofono_voicecall_driver_register() driver: > 0xdab1c, name: isimodem > ofonod[321]: src/sms.c:ofono_sms_driver_register() driver: 0xdab64, > name: isimodem > ofonod[321]: src/cbs.c:ofono_cbs_driver_register() driver: 0xdab84, > name: isimodem > ofonod[321]: src/sim.c:ofono_sim_driver_register() driver: 0xdab98, > name: isimodem > ofonod[321]: src/ussd.c:ofono_ussd_driver_register() driver: 0xdabe0, > name: isimodem > ofonod[321]: > src/call-forwarding.c:ofono_call_forwarding_driver_register() driver: > 0xdabf4, name: > isimodem > ofonod[321]: src/call-settings.c:ofono_call_settings_driver_register() > driver: 0xdac14, name: isi > modem > ofonod[321]: src/call-barring.c:ofono_call_barring_driver_register() > driver: 0xdac44, name: isimo > dem > ofonod[321]: src/call-meter.c:ofono_call_meter_driver_register() driver: > 0xdac5c, name: isimodem > ofonod[321]: src/radio-settings.c:ofono_radio_settings_driver_register() > driver: 0xdac84, name: i > simodem > ofonod[321]: src/gprs.c:ofono_gprs_driver_register() driver: 0xdaca8, > name: isimodem > ofonod[321]: src/gprs.c:ofono_gprs_context_driver_register() driver: > 0xdacbc, name: isimodem > ofonod[321]: src/audio-settings.c:ofono_audio_settings_driver_register() > driver: 0xdacd0, name: i > simodem > ofonod[321]: src/sim.c:ofono_sim_driver_register() driver: 0xdacdc, > name: wgmodem2.5 > ofonod[321]: plugins/udevng.c:udev_start() > ofonod[321]: plugins/udevng.c:enumerate_devices() > ofonod[321]: plugins/udevng.c:check_usb_device() MOSCHIP usb-ethernet > driver [9710:7830] > ofonod[321]: plugins/bluetooth.c:manager_properties_cb() > ofonod[321]: plugins/bluetooth.c:parse_adapters() > ofonod[321]: plugins/bluetooth.c:parse_adapters() Calling GetProperties > on /org/bluez/224/hci0 > ofonod[321]: plugins/bluetooth.c:adapter_properties_cb() > ofonod[321]: plugins/bluetooth.c:parse_devices() > ofonod[321]: plugins/bluetooth.c:adapter_properties_cb() Adapter > Address: 00:0C:76:D3:B9:3F, Path > : /org/bluez/224/hci0 > ofonod[321]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] > ofonod[321]: plugins/udev.c:udev_event() subsystem tty add > ofonod[321]: plugins/udev.c:udev_event() subsystem tty finished > ofonod[321]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] > ofonod[321]: plugins/udev.c:udev_event() subsystem tty add > ofonod[321]: plugins/udev.c:udev_event() subsystem tty finished > ofonod[321]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] > ofonod[321]: plugins/udev.c:udev_event() subsystem tty add > ofonod[321]: plugins/udev.c:udev_event() subsystem tty finished > ofonod[321]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] > ofonod[321]: plugins/udev.c:udev_event() subsystem tty add > ofonod[321]: plugins/udev.c:udev_event() subsystem tty finished > ofonod[321]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] > ofonod[321]: plugins/udev.c:udev_event() subsystem tty add > ofonod[321]: plugins/udev.c:udev_event() subsystem tty finished > ofonod[321]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] > ofonod[321]: plugins/udev.c:udev_event() subsystem tty add > ofonod[321]: plugins/udev.c:udev_event() subsystem tty finished > ofonod[321]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] > ofonod[321]: plugins/udev.c:udev_event() subsystem tty add > ofonod[321]: src/modem.c:ofono_modem_create() name: (null), type: telit > ofonod[321]: src/modem.c:set_modem_property() modem 0xeab98 property Path > ofonod[321]: plugins/udev.c:add_modem() > /devices/platform/musb_hdrc/usb1/1-1/1-1.3/1-1.3:1.6/tty/ > ttyACM3 (telit) > ofonod[321]: plugins/udev.c:udev_event() subsystem tty finished > ofonod[321]: plugins/udevng.c:check_modem_list() > > > root at jc-dev:~# ./test/list-modems > root at jc-dev:~# ./test/enable-modem > Traceback (most recent call last): > File "./test/enable-modem", line 14, in > path = modems[0][0] > IndexError: list index out of range > > > best regards > Jan I'm not so familiar with device exposing ttyACM interfaces, but i think that the problem is here, the cdc_acm driver is not linked with telit devices, Could you try with the following patch? -- regards, Nico -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-udevng-Add-driver-cdc_acm-to-telit-device.patch Type: text/x-patch Size: 832 bytes Desc: not available URL: From xhpohanka at gmail.com Thu Feb 9 03:39:19 2012 From: xhpohanka at gmail.com (Jan Pohanka) Date: Thu, 09 Feb 2012 12:39:19 +0100 Subject: setup ofono for telit h910 on embedded system In-Reply-To: <4F339FDC.8030700@linux.intel.com> References: <4F316099.8090005@linux.intel.com> <4F339FDC.8030700@linux.intel.com> Message-ID: Dear Nicolas, > > I'm not so familiar with device exposing ttyACM interfaces, but i think > that the problem is here, the cdc_acm driver is not linked with telit > devices, Could you try with the following patch? > I will try the patch as soon as possible, thank you. Just FYI I have tried also the ttyS1 because H910 can be controlled through USB (ttACM) interface and through UART also. Unfortunately the result was the same. regards Jan -- Tato zpr?va byla vytvo?ena p?evratn?m po?tovn?m klientem Opery: http://www.opera.com/mail/ From xhpohanka at gmail.com Thu Feb 9 04:02:08 2012 From: xhpohanka at gmail.com (Jan Pohanka) Date: Thu, 09 Feb 2012 13:02:08 +0100 Subject: setup ofono for telit h910 on embedded system In-Reply-To: <4F339FDC.8030700@linux.intel.com> References: <4F316099.8090005@linux.intel.com> <4F339FDC.8030700@linux.intel.com> Message-ID: Hello Nicolas, Dne Thu, 09 Feb 2012 11:28:44 +0100 nicolas.bertrand napsal(a): > Could you try with the following patch? I have just tried your patch and here is a new log. ofonod[132]: plugins/udev.c:udev_event() subsystem tty add ofonod[132]: plugins/udev.c:udev_event() subsystem tty finished ofonod[132]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[132]: plugins/udevng.c:add_device() /sys/devices/platform/musb_hdrc/usb1/1-1/1-1.3/1- 1.3:1.0/tty/ttyACM0 ofonod[132]: plugins/udevng.c:add_device() /dev/ttyACM0 (telit) 2/2/1 [00] ==> (null) (null) ofonod[132]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[132]: plugins/udevng.c:add_device() /sys/devices/platform/musb_hdrc/usb1/1-1/1-1.3/1- 1.3:1.10/tty/ttyACM5 ofonod[132]: plugins/udevng.c:add_device() /dev/ttyACM5 (telit) 2/2/1 [0a] ==> (null) (null) ofonod[132]: plugins/udev.c:udev_event() subsystem tty add ofonod[132]: plugins/udev.c:udev_event() subsystem tty finished ofonod[132]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[132]: plugins/udevng.c:add_device() /sys/devices/platform/musb_hdrc/usb1/1-1/1-1.3/1- 1.3:1.2/tty/ttyACM1 ofonod[132]: plugins/udevng.c:add_device() /dev/ttyACM1 (telit) 2/2/1 [02] ==> (null) (null) ofonod[132]: plugins/udev.c:udev_event() subsystem tty add ofonod[132]: plugins/udev.c:udev_event() subsystem tty finished ofonod[132]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[132]: plugins/udevng.c:add_device() /sys/devices/platform/musb_hdrc/usb1/1-1/1-1.3/1- 1.3:1.8/tty/ttyACM4 ofonod[132]: plugins/udevng.c:add_device() /dev/ttyACM4 (telit) 2/2/1 [08] ==> (null) (null) ofonod[132]: plugins/udev.c:udev_event() subsystem tty add ofonod[132]: plugins/udev.c:udev_event() subsystem tty finished ofonod[132]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[132]: plugins/udevng.c:add_device() /sys/devices/platform/musb_hdrc/usb1/1-1/1-1.3/1- 1.3:1.12/tty/ttyACM6 ofonod[132]: plugins/udevng.c:add_device() /dev/ttyACM6 (telit) 2/2/1 [0c] ==> (null) (null) ofonod[132]: plugins/udev.c:udev_event() subsystem tty add ofonod[132]: plugins/udev.c:udev_event() subsystem tty finished ofonod[132]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[132]: plugins/udevng.c:add_device() /sys/devices/platform/musb_hdrc/usb1/1-1/1-1.3/1- 1.3:1.4/tty/ttyACM2 ofonod[132]: plugins/udevng.c:add_device() /dev/ttyACM2 (telit) 2/2/1 [04] ==> (null) (null) ofonod[132]: plugins/udev.c:udev_event() subsystem tty add ofonod[132]: plugins/udev.c:udev_event() subsystem tty finished ofonod[132]: plugins/udevng.c:check_usb_device() cdc_acm [1bc7:0021] ofonod[132]: plugins/udevng.c:add_device() /sys/devices/platform/musb_hdrc/usb1/1-1/1-1.3/1- 1.3:1.6/tty/ttyACM3 ofonod[132]: plugins/udevng.c:add_device() /dev/ttyACM3 (telit) 2/2/1 [06] ==> (null) (null) ofonod[132]: plugins/udev.c:udev_event() subsystem tty add ofonod[132]: src/modem.c:ofono_modem_create() name: (null), type: telit ofonod[132]: src/modem.c:set_modem_property() modem 0xf29a8 property Path ofonod[132]: plugins/udev.c:add_modem() /devices/platform/musb_hdrc/usb1/1-1/1-1.3/1-1.3:1.6 /tty/ttyACM3 (telit) ofonod[132]: plugins/udev.c:udev_event() subsystem tty finished ofonod[132]: plugins/udevng.c:check_modem_list() ofonod[132]: plugins/udevng.c:create_modem() /sys/devices/platform/musb_hdrc/usb1/1-1/1-1.3 ofonod[132]: plugins/udevng.c:create_modem() driver=telit ofonod[132]: src/modem.c:ofono_modem_create() name: (null), type: telit ofonod[132]: plugins/udevng.c:setup_telit() /sys/devices/platform/musb_hdrc/usb1/1-1/1-1.3 ofonod[132]: plugins/udevng.c:setup_telit() /dev/ttyACM0 2/2/1 00 (null) ofonod[132]: plugins/udevng.c:setup_telit() /dev/ttyACM1 2/2/1 02 (null) ofonod[132]: plugins/udevng.c:setup_telit() /dev/ttyACM2 2/2/1 04 (null) ofonod[132]: plugins/udevng.c:setup_telit() /dev/ttyACM3 2/2/1 06 (null) ofonod[132]: plugins/udevng.c:setup_telit() /dev/ttyACM4 2/2/1 08 (null) ofonod[132]: plugins/udevng.c:setup_telit() /dev/ttyACM5 2/2/1 0a (null) ofonod[132]: plugins/udevng.c:setup_telit() /dev/ttyACM6 2/2/1 0c (null) ofonod[132]: plugins/udevng.c:destroy_modem() /sys/devices/platform/musb_hdrc/usb1/1-1/1-1.3 ofonod[132]: src/modem.c:ofono_modem_remove() 0xf2500 ofonod[132]: plugins/udevng.c:destroy_modem() /dev/ttyACM0 ofonod[132]: plugins/udevng.c:destroy_modem() /dev/ttyACM1 ofonod[132]: plugins/udevng.c:destroy_modem() /dev/ttyACM2 ofonod[132]: plugins/udevng.c:destroy_modem() /dev/ttyACM3 ofonod[132]: plugins/udevng.c:destroy_modem() /dev/ttyACM4 ofonod[132]: plugins/udevng.c:destroy_modem() /dev/ttyACM5 ofonod[132]: plugins/udevng.c:destroy_modem() /dev/ttyACM6 It seems that ofono tries to do more than before, but modem is created and removed immediately... Regarding the ttyACM3 - it behaves like serial port. I can connect it with minicom and send and receive AT commands. regards Jan -- Tato zpr?va byla vytvo?ena p?evratn?m po?tovn?m klientem Opery: http://www.opera.com/mail/ From frederic.danis at linux.intel.com Thu Feb 9 06:12:43 2012 From: frederic.danis at linux.intel.com (=?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Danis?=) Date: Thu, 9 Feb 2012 15:12:43 +0100 Subject: [PATCH] emulator: Fix start of RING event Message-ID: <1328796763-9777-1-git-send-email-frederic.danis@linux.intel.com> RING event should only be sent when callsetup indicator is set to Incoming and there is no active call. If call indicator is set to inactive while callsetup is already set to Incoming (waiting call has generated +CCWA), no RING event should be sent. Ref.: PTS test TC_AG_TWC_BV_02_I --- src/emulator.c | 18 +++--------------- 1 files changed, 3 insertions(+), 15 deletions(-) diff --git a/src/emulator.c b/src/emulator.c index 262e782..0fa6eac 100644 --- a/src/emulator.c +++ b/src/emulator.c @@ -1219,23 +1219,12 @@ void ofono_emulator_set_indicator(struct ofono_emulator *em, } /* - * Ring timer should be started when: - * - callsetup indicator is set to Incoming and there is no active call - * (not a waiting call) - * - or call indicator is set to inactive while callsetup is already - * set to Incoming. + * Ring timer should be started when callsetup indicator is set to + * Incoming and there is no active call (not a waiting call). * In those cases, a first RING should be sent just after the +CIEV * Ring timer should be stopped for all other values of callsetup */ - if (waiting) - return; - - /* Call state went from active/held + waiting -> incoming */ - if (call && value == OFONO_EMULATOR_CALL_INACTIVE && - cs_ind->value == OFONO_EMULATOR_CALLSETUP_INCOMING) - goto start_ring; - - if (!callsetup) + if (!callsetup || waiting) return; if (value != OFONO_EMULATOR_CALLSETUP_INCOMING) { @@ -1247,7 +1236,6 @@ void ofono_emulator_set_indicator(struct ofono_emulator *em, return; } -start_ring: notify_ring(em); em->callsetup_source = g_timeout_add_seconds(RING_TIMEOUT, notify_ring, em); -- 1.7.1 From rminkler at gmail.com Thu Feb 9 11:41:47 2012 From: rminkler at gmail.com (Robyn Minkler) Date: Thu, 09 Feb 2012 11:41:47 -0800 Subject: dbus error while trying to enable hfp connection with smartphone Message-ID: <1328816507.14667.5.camel@Ostrea-Edulis.lan> I'm trying to get ofono, telepathy-ring and empathy set up so that I can make and receive calls on my fedora 16 laptop. The list-modems script shows my phone, but I get a dbus error when I try to run enable-modems. More information below. Does anyone have any suggestions about how I might debug this? This is with: dbus 1.4.10 ofono 1.3 ./list-modems [ /hfp/889FFAEA6A1B_78471DBB098C ] Name = Nexus S Powered = 0 Lockdown = 0 Interfaces = Online = 0 Features = ./enable-modem Connecting modem /hfp/889FFAEA6A1B_78471DBB098C... Traceback (most recent call last): File "./enable-modem", line 20, in modem.SetProperty("Powered", dbus.Boolean(1), timeout = 120) File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 68, in __call__ return self._proxy_method(*args, **keywords) File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 140, in __call__ **keywords) File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 630, in call_blocking message, timeout) dbus.exceptions.DBusException: org.ofono.Error.Failed: Operation failed From denkenz at gmail.com Thu Feb 9 12:17:25 2012 From: denkenz at gmail.com (Denis Kenzior) Date: Thu, 09 Feb 2012 14:17:25 -0600 Subject: dbus error while trying to enable hfp connection with smartphone In-Reply-To: <1328816507.14667.5.camel@Ostrea-Edulis.lan> References: <1328816507.14667.5.camel@Ostrea-Edulis.lan> Message-ID: <4F3429D5.2050003@gmail.com> Hi Robyn, On 02/09/2012 01:41 PM, Robyn Minkler wrote: > I'm trying to get ofono, telepathy-ring and empathy set up so that I can > make and receive calls on my fedora 16 laptop. > > The list-modems script shows my phone, but I get a dbus error when I try > to run enable-modems. More information below. > > Does anyone have any suggestions about how I might debug this? export OFONO_AT_DEBUG=1 and run ofono with -d option > > This is with: > dbus 1.4.10 > ofono 1.3 > > ./list-modems > [ /hfp/889FFAEA6A1B_78471DBB098C ] > Name = Nexus S > Powered = 0 > Lockdown = 0 > Interfaces = > Online = 0 > Features = > > ./enable-modem > Connecting modem /hfp/889FFAEA6A1B_78471DBB098C... > Traceback (most recent call last): > File "./enable-modem", line 20, in > modem.SetProperty("Powered", dbus.Boolean(1), timeout = 120) > File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 68, in > __call__ > return self._proxy_method(*args, **keywords) > File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 140, in > __call__ > **keywords) > File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 630, > in call_blocking > message, timeout) > dbus.exceptions.DBusException: org.ofono.Error.Failed: Operation failed > Generally two things can go wrong: - The bluetooth link could not be established for some reason. e.g. the your adapter is off, the remote device is off, stale pairing setup, etc. Use hcidump utility from bluez to debug this. - The Handsfree SLC handshake could not be established. The AT command logs from oFono would help us diagnose that... Regards, -Denis From denkenz at gmail.com Thu Feb 9 12:22:40 2012 From: denkenz at gmail.com (Denis Kenzior) Date: Thu, 09 Feb 2012 14:22:40 -0600 Subject: [PATCH] voicecall: Fix emulator AT+CHUP for HFP In-Reply-To: <1328778754-5108-1-git-send-email-frederic.danis@linux.intel.com> References: <1328778754-5108-1-git-send-email-frederic.danis@linux.intel.com> Message-ID: <4F342B10.7040606@gmail.com> Hi Fr?d?ric, On 02/09/2012 03:12 AM, Fr?d?ric Danis wrote: > AT+CHUP should be able to hang-up active or incoming calls > --- > src/voicecall.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > Patch has been applied, thanks. Regards, -Denis From rminkler at gmail.com Thu Feb 9 15:25:52 2012 From: rminkler at gmail.com (Robyn Minkler) Date: Thu, 09 Feb 2012 15:25:52 -0800 Subject: dbus error while trying to enable hfp connection with smartphone In-Reply-To: <4F3429D5.2050003@gmail.com> References: <1328816507.14667.5.camel@Ostrea-Edulis.lan> <4F3429D5.2050003@gmail.com> Message-ID: <1328829952.14709.6.camel@Ostrea-Edulis.lan> Hi Denis, ofonod is throwing this error when I run enable-modem: ofonod[17676]: plugins/hfp_hf.c:hfp_connect_reply() Connect reply: Method "Connect" with signature "" on interface "org.bluez.HandsfreeGateway" doesn't exist Is this helpful? Here's the rest of the ofonod output: ofonod[17829]: oFono version 0.44 ofonod[17829]: src/plugin.c:__ofono_plugin_init() ofonod[17829]: plugins/push-notification.c:push_notification_init() ofonod[17829]: plugins/smart-messaging.c:smart_messaging_init() ofonod[17829]: plugins/dun_gw.c:dun_gw_init() ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x700180, name: hfp ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x7000a0, name: linktop ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x700000, name: nokiacdma ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x6fff60, name: nokia ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x6ffec0, name: tc65 ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x6ffda0, name: ste ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x6ffd00, name: ifx ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x6ffc60, name: palmpre ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x6ffbc0, name: novatel ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x6ffb20, name: sierra ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x6ffa60, name: huawei ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x6ff9c0, name: zte ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x6ff900, name: hso ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x6ff840, name: mbm ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x6ff7a0, name: calypso ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x6ff700, name: wavecom ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x6ff660, name: gobi ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x6ff5c0, name: g1 ofonod[17829]: src/cdma-voicecall.c:ofono_cdma_voicecall_driver_register() driver: 0x6ff500, name: cdmamodem ofonod[17829]: src/modem.c:ofono_devinfo_driver_register() driver: 0x6ff540, name: cdmamodem ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x6ff460, name: phonesim ofonod[17829]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x6ff420, name: phonesim ofonod[17829]: src/ctm.c:ofono_ctm_driver_register() driver: 0x6ff3e0, name: phonesim ofonod[17829]: plugins/phonesim.c:parse_config() filename /etc/ofono/phonesim.conf ofonod[17829]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x6ff220, name: stemodem ofonod[17829]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x6ff320, name: stemodem ofonod[17829]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x6ff2c0, name: stemodem ofonod[17829]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x6fefc0, name: ifxmodem ofonod[17829]: src/audio-settings.c:ofono_audio_settings_driver_register() driver: 0x6ff050, name: ifxmodem ofonod[17829]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x6ff080, name: ifxmodem ofonod[17829]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x6ff0e0, name: ifxmodem ofonod[17829]: src/stk.c:ofono_stk_driver_register() driver: 0x6ff140, name: ifxmodem ofonod[17829]: src/ctm.c:ofono_ctm_driver_register() driver: 0x6ff1a0, name: ifxmodem ofonod[17829]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x6feee0, name: hsomodem ofonod[17829]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x6fef20, name: hsomodem ofonod[17829]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x6fedc0, name: mbmmodem ofonod[17829]: src/stk.c:ofono_stk_driver_register() driver: 0x6fee20, name: mbmmodem ofonod[17829]: src/location-reporting.c:ofono_location_reporting_driver_register() driver: 0x6fee60, name: mbmmodem ofonod[17829]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x6fec00, name: hfpmodem ofonod[17829]: src/network.c:ofono_netreg_driver_register() driver: 0x6feca0, name: hfpmodem ofonod[17829]: src/call-volume.c:ofono_call_volume_driver_register() driver: 0x6fed20, name: hfpmodem ofonod[17829]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x6feae0, name: calypsomodem ofonod[17829]: src/stk.c:ofono_stk_driver_register() driver: 0x6feb80, name: calypsomodem ofonod[17829]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x6fe940, name: huaweimodem ofonod[17829]: src/audio-settings.c:ofono_audio_settings_driver_register() driver: 0x6fe9d0, name: huaweimodem ofonod[17829]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x6fea40, name: huaweimodem ofonod[17829]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x6fea00, name: huaweimodem ofonod[17829]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x6fe8a0, name: nwmodem ofonod[17829]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x6fe560, name: atmodem ofonod[17829]: src/modem.c:ofono_devinfo_driver_register() driver: 0x6fe6e0, name: atmodem ofonod[17829]: src/call-barring.c:ofono_call_barring_driver_register() driver: 0x6fe620, name: atmodem ofonod[17829]: src/call-forwarding.c:ofono_call_forwarding_driver_register() driver: 0x6fe1c0, name: atmodem ofonod[17829]: src/call-meter.c:ofono_call_meter_driver_register() driver: 0x6fe220, name: atmodem ofonod[17829]: src/call-settings.c:ofono_call_settings_driver_register() driver: 0x6fdfe0, name: atmodem ofonod[17829]: src/phonebook.c:ofono_phonebook_driver_register() driver: 0x6fe660, name: atmodem ofonod[17829]: src/ssn.c:ofono_ssn_driver_register() driver: 0x6fe6b0, name: atmodem ofonod[17829]: src/ussd.c:ofono_ussd_driver_register() driver: 0x6fe500, name: atmodem ofonod[17829]: src/sms.c:ofono_sms_driver_register() driver: 0x6fe0c0, name: atmodem ofonod[17829]: src/sim.c:ofono_sim_driver_register() driver: 0x6fe380, name: atmodem ofonod[17829]: src/stk.c:ofono_stk_driver_register() driver: 0x6fe4a0, name: atmodem ofonod[17829]: src/network.c:ofono_netreg_driver_register() driver: 0x6fe2c0, name: atmodem ofonod[17829]: src/cbs.c:ofono_cbs_driver_register() driver: 0x6fe180, name: atmodem ofonod[17829]: src/call-volume.c:ofono_call_volume_driver_register() driver: 0x6fe720, name: atmodem ofonod[17829]: src/gprs.c:ofono_gprs_driver_register() driver: 0x6fe780, name: atmodem ofonod[17829]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x6fe7e0, name: atmodem ofonod[17829]: src/sim-auth.c:ofono_sim_auth_driver_register() driver: 0x6fe820, name: atmodem ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x6fdd60, name: u8500 ofonod[17829]: src/modem.c:ofono_devinfo_driver_register() driver: 0x6fdd20, name: u8500 ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x6fdc80, name: n900 ofonod[17829]: src/modem.c:ofono_modem_driver_register() driver: 0x6fdbe0, name: isiusb ofonod[17829]: src/modem.c:ofono_devinfo_driver_register() driver: 0x6fd640, name: isimodem ofonod[17829]: src/phonebook.c:ofono_phonebook_driver_register() driver: 0x6fd620, name: isimodem ofonod[17829]: src/network.c:ofono_netreg_driver_register() driver: 0x6fd680, name: isimodem ofonod[17829]: src/network.c:ofono_netreg_driver_register() driver: 0x6fd6e0, name: wgmodem2.5 ofonod[17829]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x6fd740, name: isimodem ofonod[17829]: src/sms.c:ofono_sms_driver_register() driver: 0x6fd7e0, name: isimodem ofonod[17829]: src/cbs.c:ofono_cbs_driver_register() driver: 0x6fd820, name: isimodem ofonod[17829]: src/sim.c:ofono_sim_driver_register() driver: 0x6fd860, name: isimodem ofonod[17829]: src/ssn.c:ofono_ssn_driver_register() driver: 0x6fd8f0, name: isimodem ofonod[17829]: src/ussd.c:ofono_ussd_driver_register() driver: 0x6fd920, name: isimodem ofonod[17829]: src/call-forwarding.c:ofono_call_forwarding_driver_register() driver: 0x6fd960, name: isimodem ofonod[17829]: src/call-settings.c:ofono_call_settings_driver_register() driver: 0x6fd9a0, name: isimodem ofonod[17829]: src/call-barring.c:ofono_call_barring_driver_register() driver: 0x6fda00, name: isimodem ofonod[17829]: src/call-meter.c:ofono_call_meter_driver_register() driver: 0x6fda40, name: isimodem ofonod[17829]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x6fdaa0, name: isimodem ofonod[17829]: src/gprs.c:ofono_gprs_driver_register() driver: 0x6fdb00, name: isimodem ofonod[17829]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x6fdb40, name: isimodem ofonod[17829]: src/audio-settings.c:ofono_audio_settings_driver_register() driver: 0x6fdb70, name: isimodem ofonod[17829]: plugins/bluetooth.c:manager_properties_cb() ofonod[17829]: plugins/bluetooth.c:parse_adapters() ofonod[17829]: plugins/bluetooth.c:parse_adapters() Calling GetProperties on /org/bluez/17603/hci0 ofonod[17829]: plugins/bluetooth.c:adapter_properties_cb() ofonod[17829]: plugins/bluetooth.c:parse_devices() ofonod[17829]: plugins/bluetooth.c:adapter_properties_cb() Adapter Address: 88:9F:FA:EA:6A:1B, Path: /org/bluez/17603/hci0 ofonod[17829]: plugins/bluetooth.c:device_properties_cb() ofonod[17829]: Using device: /org/bluez/17603/hci0/dev_78_47_1D_BB_09_8C, devaddr: 78:47:1D:BB:09:8C, adapter: 88:9F:FA:EA:6A:1B ofonod[17829]: src/modem.c:ofono_modem_create() name: hfp/889FFAEA6A1B_78471DBB098C, type: hfp ofonod[17829]: plugins/hfp_hf.c:hfp_register_ofono_handsfree() Registering oFono Agent to bluetooth daemon ofonod[17829]: plugins/hfp_ag.c:modem_watch() modem: 0x23a8490, added: 1 ofonod[17829]: plugins/dun_gw.c:modem_watch() modem: 0x23a8490, added: 1 ofonod[17829]: plugins/smart-messaging.c:modem_watch() modem: 0x23a8490, added: 1 ofonod[17829]: plugins/push-notification.c:modem_watch() modem: 0x23a8490, added: 1 ofonod[17829]: plugins/bluetooth.c:device_properties_cb() ofonod[17829]: plugins/hfp_hf.c:hfp_enable() 0x23a8490 ofonod[17829]: plugins/hfp_hf.c:hfp_connect_reply() Connect reply: Method "Connect" with signature "" on interface "org.bluez.HandsfreeGateway" doesn't exist Thanks, Robyn On Thu, 2012-02-09 at 14:17 -0600, Denis Kenzior wrote: > Hi Robyn, > > On 02/09/2012 01:41 PM, Robyn Minkler wrote: > > I'm trying to get ofono, telepathy-ring and empathy set up so that I can > > make and receive calls on my fedora 16 laptop. > > > > The list-modems script shows my phone, but I get a dbus error when I try > > to run enable-modems. More information below. > > > > Does anyone have any suggestions about how I might debug this? > > export OFONO_AT_DEBUG=1 and run ofono with -d option > > > > > This is with: > > dbus 1.4.10 > > ofono 1.3 > > > > ./list-modems > > [ /hfp/889FFAEA6A1B_78471DBB098C ] > > Name = Nexus S > > Powered = 0 > > Lockdown = 0 > > Interfaces = > > Online = 0 > > Features = > > > > ./enable-modem > > Connecting modem /hfp/889FFAEA6A1B_78471DBB098C... > > Traceback (most recent call last): > > File "./enable-modem", line 20, in > > modem.SetProperty("Powered", dbus.Boolean(1), timeout = 120) > > File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 68, in > > __call__ > > return self._proxy_method(*args, **keywords) > > File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 140, in > > __call__ > > **keywords) > > File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 630, > > in call_blocking > > message, timeout) > > dbus.exceptions.DBusException: org.ofono.Error.Failed: Operation failed > > > > Generally two things can go wrong: > > - The bluetooth link could not be established for some reason. e.g. the > your adapter is off, the remote device is off, stale pairing setup, etc. > Use hcidump utility from bluez to debug this. > > - The Handsfree SLC handshake could not be established. The AT command > logs from oFono would help us diagnose that... > > Regards, > -Denis From denkenz at gmail.com Thu Feb 9 16:19:30 2012 From: denkenz at gmail.com (Denis Kenzior) Date: Thu, 09 Feb 2012 18:19:30 -0600 Subject: dbus error while trying to enable hfp connection with smartphone In-Reply-To: <1328829952.14709.6.camel@Ostrea-Edulis.lan> References: <1328816507.14667.5.camel@Ostrea-Edulis.lan> <4F3429D5.2050003@gmail.com> <1328829952.14709.6.camel@Ostrea-Edulis.lan> Message-ID: <4F346292.4010103@gmail.com> On 02/09/2012 05:25 PM, Robyn Minkler wrote: > Hi Denis, > > ofonod is throwing this error when I run enable-modem: > > ofonod[17676]: plugins/hfp_hf.c:hfp_connect_reply() Connect reply: > Method "Connect" with signature "" on interface > "org.bluez.HandsfreeGateway" doesn't exist > > Is this helpful? > Sounds like your BlueZ is not configured properly. Try adding Enable=Gateway to the [General] section of your /etc/bluetooth/audio.conf. Regards, -Denis From denkenz at gmail.com Wed Feb 15 03:27:47 2012 From: denkenz at gmail.com (Denis Kenzior) Date: Wed, 15 Feb 2012 05:27:47 -0600 Subject: [PATCH] emulator: Fix start of RING event In-Reply-To: <1328796763-9777-1-git-send-email-frederic.danis@linux.intel.com> References: <1328796763-9777-1-git-send-email-frederic.danis@linux.intel.com> Message-ID: <4F3B96B3.1060202@gmail.com> Hi Fred, On 02/09/2012 08:12 AM, Fr?d?ric Danis wrote: > RING event should only be sent when callsetup indicator is set to > Incoming and there is no active call. > > If call indicator is set to inactive while callsetup is > already set to Incoming (waiting call has generated +CCWA), > no RING event should be sent. > > Ref.: PTS test TC_AG_TWC_BV_02_I > --- > src/emulator.c | 18 +++--------------- > 1 files changed, 3 insertions(+), 15 deletions(-) > After looking at the test case, it seems to be dealing with testing the consequences of CHLD=1. Essentially dropping the current active call and accepting the waiting call. The logic you're changing is also dealing with a slightly different case, namely if the active call is dropped by the remote party during a waiting call. In the case of CHLD=1, the sequence should be one of these: 1. Active Call Index -> Disconnected, Waiting call Index -> Active In the case of remote party dropping the Active call, the sequences can be: 1. Active Call Index -> Disconnected, Waiting Call Index -> Incoming The logic has to be modified to handle the transition state (e.g. call indicator going from 1 to 0, and waiting call present) and send the proper indicators when the final state is reached. Likely our handling of the 'waiting' variable is incorrect, we cannot rely on the values of callsetup and call, but instead should try to find any calls in the 'WAITING' state. I believe that sending a call=0, then callsetup=0, call=1 is acceptable, but ideally in the case of CHLD=1 we should be sending callsetup=0 only. Regards, -Denis From philippe.nunes at linux.intel.com Thu Feb 16 03:32:49 2012 From: philippe.nunes at linux.intel.com (Philippe Nunes) Date: Thu, 16 Feb 2012 12:32:49 +0100 Subject: [PATCH] call-volume.c: Register the call-volume interface just after the +CMUT query Message-ID: <1329391969-13810-1-git-send-email-philippe.nunes@linux.intel.com> With this change, the mute status and the volume level are initialised in the call-volume atom. This allows also to expose the call-volume interface even if the command +CLVL is not supported as it is the case for IFX. --- drivers/atmodem/call-volume.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/atmodem/call-volume.c b/drivers/atmodem/call-volume.c index e2535b1..4c32ba7 100644 --- a/drivers/atmodem/call-volume.c +++ b/drivers/atmodem/call-volume.c @@ -65,6 +65,7 @@ static void cmut_query(gboolean ok, GAtResult *result, gpointer user_data) if (g_at_result_iter_next_number(&iter, &muted) == FALSE) return; + ofono_call_volume_register(cv); ofono_call_volume_set_muted(cv, muted); } @@ -94,7 +95,6 @@ static void clvl_query(gboolean ok, GAtResult *result, gpointer user_data) (cvd->clvl_max - cvd->clvl_min); ofono_call_volume_set_speaker_volume(cv, percent); - ofono_call_volume_register(cv); } static void clvl_range_query(gboolean ok, GAtResult *result, gpointer user_data) -- 1.7.1 From jussi.kukkonen at intel.com Tue Feb 21 07:20:58 2012 From: jussi.kukkonen at intel.com (Jussi Kukkonen) Date: Tue, 21 Feb 2012 17:20:58 +0200 Subject: trying to understand context creation Message-ID: Hi, I'm looking at how I'm creating and using internet contexts to make sure I'm not missing any problem cases, and I feel like I don't have much feedback on what is happening and what possibly scenarios I should be ready for. Dennis explained the ConnectionManager "life time" last week which helped a lot (thanks) but I'm still struggling. I've listed some steps that may happen from user/GUI point of view and the questions I have (some are connman related but I think this is still the better list): * Modem with ConnectionManager appears A ConnectionContext may have been created automatically or not. Under what circumstances does this happen? E.g. If the mobile broadband db contains several plans for a MNC/MCC does ofono try them until one works or is the selection left to user? Are there checks to make sure the created context is valid for the network? * If a ConnectionContext does not appear, UI/user may create one. using ConnectionManager.AddContext() and ConnectionContext.SetProperty(). Are there checks at this point to ensure that the created context is valid and should work? If not, is there anythign I can do to check context validity? * Connman exposes a cellular service What are the conditions for this to happen? If connman exposes a service, should that "Just work" (with normal caveats about internet connections) or does it appear for any context that has been created? * Finally, user can connect the cellular service exposed by connman If the connection with a cellular service fails, is there anything else than "Error=connect-failed" to work with? What are the potential reasons for this -- is it just the normal issues with any network connection, or can e.g. broken APN settings be a reason for failure at this point? In case background helps to understand it, this uncertainty came to be from two issues (possibly related ones): 1. a tester is telling me nothing happens when he selects his plan using dawati networks panel (ofono is 1.0 so automatic context creation does not work), in other words the service isn't appearing in connman. Now, I know how to start digging to the specific problem in this case, but I'd like to make sure I'm handling all the relevant error cases... What are the possible points of failure in this? Is it just the method calls in ConnectionManager and ConnectionContext plus Connman Service.Error after trying to connect to the service? 2. I've been testing ofono 1.4 and it seems I can succesfully create a context with any values of APN/username/password and a connman service will appear. Is this supposed to happen? (Calling Connect() on this service will timeout and in the end set "Error=connect-failed", which is to be expected) - Jussi From denkenz at gmail.com Tue Feb 21 06:03:41 2012 From: denkenz at gmail.com (Denis Kenzior) Date: Tue, 21 Feb 2012 08:03:41 -0600 Subject: trying to understand context creation In-Reply-To: References: Message-ID: <4F43A43D.3020503@gmail.com> Hi Jussi, On 02/21/2012 09:20 AM, Jussi Kukkonen wrote: > Hi, > I'm looking at how I'm creating and using internet contexts to make > sure I'm not missing any problem cases, and I feel like I don't have > much feedback on what is happening and what possibly scenarios I > should be ready for. Dennis explained the ConnectionManager "life > time" last week which helped a lot (thanks) but I'm still struggling. > > I've listed some steps that may happen from user/GUI point of view and > the questions I have (some are connman related but I think this is > still the better list): > > * Modem with ConnectionManager appears > A ConnectionContext may have been created automatically or not. Under > what circumstances does this happen? E.g. If the mobile broadband db > contains several plans for a MNC/MCC does ofono try them until one > works or is the selection left to user? Are there checks to make sure > the created context is valid for the network? Actually this is really rather straight forward. 1. oFono obtains the IMSI from the Sim Card, this is a unique identifier of the subscriber. 2. If the IMSI has not been seen before (e.g. a new never before sim card is inserted) proceed to step 2a. 2a. oFono obtains MCC/MNC & SPN from the SIM file system, and asks any provisioning plugins to provide context information. The contract between the provisioning plugin and oFono is that the information provided must be unique. E.g. if there are any conflicts, or multiple matches for a given mcc/mnc/spn then provisioning should fail. Successful provisioning results in a set of contexts being created before ConnectionManager interface is registered. 2b. If provisioning fails or mcc/mnc information is not known (e.g. inadequate modem driver support) then a single, default, empty context is created. 3. If the IMSI has been seen before, then any contexts created previously are loaded from the IMSI-keyed storage. This includes the unprovisioned 'default, empty context' if it hasn't been provisioned previously. So to sum up, from a UI point of view, you only need to care about provisioning if the UI detects a single, empty context of type 'internet' with empty APN/username/password. And no, there is absolutely no way to know whether a given context settings are valid, but a good indication would be that a context activation fails. > > * If a ConnectionContext does not appear, UI/user may create one. > using ConnectionManager.AddContext() and > ConnectionContext.SetProperty(). > Are there checks at this point to ensure that the created context is > valid and should work? If not, is there anythign I can do to check > context validity? Not really > > * Connman exposes a cellular service > What are the conditions for this to happen? If connman exposes a > service, should that "Just work" (with normal caveats about internet > connections) or does it appear for any context that has been created? Connman only cares about internet contexts, and its services are populated from the same ConnectionManager context list. There are no further filtering rules other than the context type. > > * Finally, user can connect the cellular service exposed by connman > If the connection with a cellular service fails, is there anything > else than "Error=connect-failed" to work with? What are the potential not at this time > reasons for this -- is it just the normal issues with any network > connection, or can e.g. broken APN settings be a reason for failure at > this point? > Yes, broken APN settings can and do cause connection failures. > > In case background helps to understand it, this uncertainty came to be > from two issues (possibly related ones): > 1. a tester is telling me nothing happens when he selects his plan > using dawati networks panel (ofono is 1.0 so automatic context > creation does not work), in other words the service isn't appearing in > connman. Now, I know how to start digging to the specific problem in > this case, but I'd like to make sure I'm handling all the relevant > error cases... What are the possible points of failure in this? Is it > just the method calls in ConnectionManager and ConnectionContext plus > Connman Service.Error after trying to connect to the service? If the service isn't appearing, then likely the context is not being created properly... > 2. I've been testing ofono 1.4 and it seems I can succesfully create a > context with any values of APN/username/password and a connman service > will appear. Is this supposed to happen? (Calling Connect() on this > service will timeout and in the end set "Error=connect-failed", which > is to be expected) > Yes, this is supposed to happen. It is rather unfortunate that the user has to know this information, however at this time we have not heard / seen any standard for provisioning context settings other than the widely used approach of consulting an external database. This approach still requires user intervention a lot of times due to varying carrier plans. Regards, -Denis From jussi.kukkonen at intel.com Wed Feb 22 01:58:07 2012 From: jussi.kukkonen at intel.com (Jussi Kukkonen) Date: Wed, 22 Feb 2012 11:58:07 +0200 Subject: trying to understand context creation In-Reply-To: <4F43A43D.3020503@gmail.com> References: <4F43A43D.3020503@gmail.com> Message-ID: On Tue, Feb 21, 2012 at 4:03 PM, Denis Kenzior wrote: > Hi Jussi, Hi, thanks for clarification, it helps a lot. > On 02/21/2012 09:20 AM, Jussi Kukkonen wrote: [clip] >> * Modem with ConnectionManager appears >> A ConnectionContext may have been created automatically or not. Under >> what ?circumstances does this happen? E.g. If the mobile broadband db >> contains several plans for a MNC/MCC does ofono try them until one >> works or is the selection left to user? Are there checks to make sure >> the created context is valid for the network? > > Actually this is really rather straight forward. > 1. oFono obtains the IMSI from the Sim Card, this is a unique identifier > of the subscriber. > 2. If the IMSI has not been seen before (e.g. a new never before sim > card is inserted) proceed to step 2a. > 2a. oFono obtains MCC/MNC & SPN from the SIM file system, and asks any > provisioning plugins to provide context information. ?The contract > between the provisioning plugin and oFono is that the information > provided must be unique. ?E.g. if there are any conflicts, or multiple > matches for a given mcc/mnc/spn then provisioning should fail. > Successful provisioning results in a set of contexts being created > before ConnectionManager interface is registered. > 2b. If provisioning fails or mcc/mnc information is not known (e.g. > inadequate modem driver support) then a single, default, empty context > is created. > 3. If the IMSI has been seen before, then any contexts created > previously are loaded from the IMSI-keyed storage. ?This includes the > unprovisioned 'default, empty context' if it hasn't been provisioned > previously. > So to sum up, from a UI point of view, you only need to care about > provisioning if the UI detects a single, empty context of type > 'internet' with empty APN/username/password. or if the user explicitly tells me he wants to mess the context up manually -- I will have to provide this possibility at all times if there's no way of knowing whether specific settings are considered valid by the network. > And no, there is absolutely no way to know whether a given context > settings are valid, but a good indication would be that a context > activation fails. Aha... would you consider it a good/bad idea if a configuration UI activated/deactivated the context after modifications to check for this? This could be useful to say "We couldn't connect to the network with these settings, would you like try another configuration?" - Jussi From r.r.zaripov at gmail.com Wed Feb 22 04:18:37 2012 From: r.r.zaripov at gmail.com (r.r.zaripov at gmail.com) Date: Wed, 22 Feb 2012 16:18:37 +0400 Subject: [PATCH] sim900: Using AT+SPIC for obtaining times remains input SIM PIN/PUK Message-ID: <1329913117-19530-1-git-send-email-r.r.zaripov@gmail.com> From: Renat Zaripov In SIMCOM SIM900 not implemented AT+CPINR, but possible use AT+SPIC instead this one. AT+SPIC Times Remained to Input SIM PIN/PUK +SPIC: ,,, Parameters Times remained to input chv1 Times remained to input chv2 Times remained to input puk1 Times remained to input puk2 --- drivers/atmodem/sim.c | 45 +++++++++++++++++++++++++++++++++++++++++++++ plugins/sim900.c | 2 +- 2 files changed, 46 insertions(+), 1 deletions(-) diff --git a/drivers/atmodem/sim.c b/drivers/atmodem/sim.c index 8edd582..8ee9822 100644 --- a/drivers/atmodem/sim.c +++ b/drivers/atmodem/sim.c @@ -62,6 +62,7 @@ static const char *zpinpuk_prefix[] = { "+ZPINPUK:", NULL }; static const char *oercn_prefix[] = { "_OERCN:", NULL }; static const char *cpinr_prefixes[] = { "+CPINR:", "+CPINRE:", NULL }; static const char *epin_prefix[] = { "*EPIN:", NULL }; +static const char *spic_prefix[] = { "+SPIC:", NULL }; static const char *none_prefix[] = { NULL }; static void at_crsm_info_cb(gboolean ok, GAtResult *result, gpointer user_data) @@ -800,6 +801,45 @@ static void at_cpinr_cb(gboolean ok, GAtResult *result, gpointer user_data) cb(&error, retries, cbd->data); } +static void at_spic_cb(gboolean ok, GAtResult *result, gpointer user_data) +{ + struct cb_data *cbd = user_data; + ofono_sim_pin_retries_cb_t cb = cbd->cb; + const char *final = g_at_result_final_response(result); + GAtResultIter iter; + struct ofono_error error; + int retries[OFONO_SIM_PASSWORD_INVALID]; + size_t i; + static enum ofono_sim_password_type password_types[] = { + OFONO_SIM_PASSWORD_SIM_PIN, + OFONO_SIM_PASSWORD_SIM_PUK, + OFONO_SIM_PASSWORD_SIM_PIN2, + OFONO_SIM_PASSWORD_SIM_PUK2, + }; + + decode_at_error(&error, final); + + if (!ok) { + cb(&error, NULL, cbd->data); + return; + } + + g_at_result_iter_init(&iter, result); + + if (!g_at_result_iter_next(&iter, "+SPIC:")) + goto error; + + BUILD_PIN_RETRIES_ARRAY(password_types, ARRAY_SIZE(password_types), + retries); + + cb(&error, retries, cbd->data); + + return; + +error: + CALLBACK_WITH_FAILURE(cb, NULL, cbd->data); +} + static void at_pin_retries_query(struct ofono_sim *sim, ofono_sim_pin_retries_cb_t cb, void *data) @@ -840,6 +880,11 @@ static void at_pin_retries_query(struct ofono_sim *sim, at_epin_cb, cbd, g_free) > 0) return; break; + case OFONO_VENDOR_SIMCOM: + if (g_at_chat_send(sd->chat, "AT+SPIC", spic_prefix, + at_spic_cb, cbd, g_free) > 0) + return; + break; default: if (g_at_chat_send(sd->chat, "AT+CPINR", cpinr_prefixes, at_cpinr_cb, cbd, g_free) > 0) diff --git a/plugins/sim900.c b/plugins/sim900.c index bc5f9c5..87d640f 100644 --- a/plugins/sim900.c +++ b/plugins/sim900.c @@ -210,7 +210,7 @@ static void sim900_pre_sim(struct ofono_modem *modem) DBG("%p", modem); ofono_devinfo_create(modem, 0, "atmodem", data->modem); - sim = ofono_sim_create(modem, 0, "atmodem", data->modem); + sim = ofono_sim_create(modem, OFONO_VENDOR_SIMCOM, "atmodem", data->modem); if (sim) ofono_sim_inserted_notify(sim, TRUE); -- 1.7.7.3 From denkenz at gmail.com Wed Feb 22 01:19:25 2012 From: denkenz at gmail.com (Denis Kenzior) Date: Wed, 22 Feb 2012 03:19:25 -0600 Subject: trying to understand context creation In-Reply-To: References: <4F43A43D.3020503@gmail.com> Message-ID: <4F44B31D.2050501@gmail.com> Hi Jussi, On 02/22/2012 03:58 AM, Jussi Kukkonen wrote: > On Tue, Feb 21, 2012 at 4:03 PM, Denis Kenzior wrote: >> Hi Jussi, > > Hi, thanks for clarification, it helps a lot. > >> On 02/21/2012 09:20 AM, Jussi Kukkonen wrote: > [clip] >>> * Modem with ConnectionManager appears >>> A ConnectionContext may have been created automatically or not. Under >>> what circumstances does this happen? E.g. If the mobile broadband db >>> contains several plans for a MNC/MCC does ofono try them until one >>> works or is the selection left to user? Are there checks to make sure >>> the created context is valid for the network? >> >> Actually this is really rather straight forward. >> 1. oFono obtains the IMSI from the Sim Card, this is a unique identifier >> of the subscriber. >> 2. If the IMSI has not been seen before (e.g. a new never before sim >> card is inserted) proceed to step 2a. >> 2a. oFono obtains MCC/MNC & SPN from the SIM file system, and asks any >> provisioning plugins to provide context information. The contract >> between the provisioning plugin and oFono is that the information >> provided must be unique. E.g. if there are any conflicts, or multiple >> matches for a given mcc/mnc/spn then provisioning should fail. >> Successful provisioning results in a set of contexts being created >> before ConnectionManager interface is registered. >> 2b. If provisioning fails or mcc/mnc information is not known (e.g. >> inadequate modem driver support) then a single, default, empty context >> is created. >> 3. If the IMSI has been seen before, then any contexts created >> previously are loaded from the IMSI-keyed storage. This includes the >> unprovisioned 'default, empty context' if it hasn't been provisioned >> previously. >> So to sum up, from a UI point of view, you only need to care about >> provisioning if the UI detects a single, empty context of type >> 'internet' with empty APN/username/password. > > or if the user explicitly tells me he wants to mess the context up > manually -- I will have to provide this possibility at all times if > there's no way of knowing whether specific settings are considered > valid by the network. Yep, sounds good. > >> And no, there is absolutely no way to know whether a given context >> settings are valid, but a good indication would be that a context >> activation fails. > > Aha... would you consider it a good/bad idea if a configuration UI > activated/deactivated the context after modifications to check for > this? This could be useful to say "We couldn't connect to the network > with these settings, would you like try another configuration?" > I'm generally in favor of not over-complicating this, but instead relying on the provisioning data as much as possible. Look at iOS for a good example, the user doesn't have any UI to edit context settings, it is all provisioned using carrier profiles. Granted, the provisioning database in use is a little bit better than what mobile-broadband-provider-info provides, so some way to manually enter details would still be required in our case; however we should strive to make this as rarely used as possible. What you suggest is a good idea, but might be overkill... Regards, -Denis From denkenz at gmail.com Wed Feb 22 02:19:01 2012 From: denkenz at gmail.com (Denis Kenzior) Date: Wed, 22 Feb 2012 04:19:01 -0600 Subject: [PATCH] sim900: Using AT+SPIC for obtaining times remains input SIM PIN/PUK In-Reply-To: <1329913117-19530-1-git-send-email-r.r.zaripov@gmail.com> References: <1329913117-19530-1-git-send-email-r.r.zaripov@gmail.com> Message-ID: <4F44C115.9060506@gmail.com> Hi Renat, On 02/22/2012 06:18 AM, r.r.zaripov at gmail.com wrote: > From: Renat Zaripov > > In SIMCOM SIM900 not implemented AT+CPINR, but possible use AT+SPIC > instead this one. > > AT+SPIC Times Remained to Input SIM PIN/PUK > > +SPIC: ,,, > > Parameters > Times remained to input chv1 > Times remained to input chv2 > Times remained to input puk1 > Times remained to input puk2 > --- > drivers/atmodem/sim.c | 45 +++++++++++++++++++++++++++++++++++++++++++++ > plugins/sim900.c | 2 +- > 2 files changed, 46 insertions(+), 1 deletions(-) > I broke this patch up into two, one for drivers/atmodem changes and one for plugins/ changes. Please refer to item 3) in 'Submitting patches' section of the HACKING document. I also re-worded the commit message slightly and applied the patch. Thanks! Regards, -Denis From denkenz at gmail.com Wed Feb 22 02:25:06 2012 From: denkenz at gmail.com (Denis Kenzior) Date: Wed, 22 Feb 2012 04:25:06 -0600 Subject: [PATCHv2 1/8] call-forwarding: Minor style fixes In-Reply-To: <1328531641-10612-2-git-send-email-oleg.zhurakivskyy@intel.com> References: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> <1328531641-10612-2-git-send-email-oleg.zhurakivskyy@intel.com> Message-ID: <4F44C282.3070700@gmail.com> Hi Oleg, On 02/06/2012 06:33 AM, Oleg Zhurakivskyy wrote: > --- > src/call-forwarding.c | 56 ++++++++++++++++++++++++++---------------------- > 1 files changed, 30 insertions(+), 26 deletions(-) > Patch has been applied, thanks. Regards, -Denis From denkenz at gmail.com Wed Feb 22 02:25:24 2012 From: denkenz at gmail.com (Denis Kenzior) Date: Wed, 22 Feb 2012 04:25:24 -0600 Subject: [PATCHv2 2/8] call-forwarding: Minor refactoring of is_cfu_enabled() In-Reply-To: <1328531641-10612-3-git-send-email-oleg.zhurakivskyy@intel.com> References: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> <1328531641-10612-3-git-send-email-oleg.zhurakivskyy@intel.com> Message-ID: <4F44C294.5040501@gmail.com> Hi Oleg, On 02/06/2012 06:33 AM, Oleg Zhurakivskyy wrote: > This also removes the need for uninitialized_var() macro. > --- > src/call-forwarding.c | 36 +++++++++++++++++------------------- > 1 files changed, 17 insertions(+), 19 deletions(-) > Patch has been applied, thanks. Regards, -Denis From denkenz at gmail.com Wed Feb 22 02:34:43 2012 From: denkenz at gmail.com (Denis Kenzior) Date: Wed, 22 Feb 2012 04:34:43 -0600 Subject: [PATCHv2 3/8] call-forwarding: Don't set conditional cfs when cfu is active In-Reply-To: <1328531641-10612-4-git-send-email-oleg.zhurakivskyy@intel.com> References: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> <1328531641-10612-4-git-send-email-oleg.zhurakivskyy@intel.com> Message-ID: <4F44C4C3.8070803@gmail.com> Hi Oleg, On 02/06/2012 06:33 AM, Oleg Zhurakivskyy wrote: > --- > src/call-forwarding.c | 18 ++++++++++++++++++ > 1 files changed, 18 insertions(+), 0 deletions(-) > > diff --git a/src/call-forwarding.c b/src/call-forwarding.c > index 8b8d5a8..3f9d816 100644 > --- a/src/call-forwarding.c > +++ b/src/call-forwarding.c > @@ -802,6 +802,13 @@ static DBusMessage *cf_set_property(DBusConnection *conn, DBusMessage *msg, > if (strlen(number) > 0 && !valid_phone_number_format(number)) > return __ofono_error_invalid_format(msg); > > + /* > + * Don't set conditional cfs when cfu is active > + */ > + if (type != CALL_FORWARDING_TYPE_UNCONDITIONAL && > + number[0] != '\0' && is_cfu_enabled(cf)) > + return __ofono_error_not_available(msg); > + > if (number[0] != '\0') > string_to_phone_number(number, &ph); > I applied this chunk... > @@ -1159,6 +1166,17 @@ static gboolean cf_ss_control(int type, const char *sc, > return TRUE; > } > > + /* > + * Don't set conditional cfs when cfu is active > + */ > + if (type == SS_CONTROL_TYPE_REGISTRATION && You are not handling SS_CONTROL_TYPE_ACTIVATION here... > + cf_type != CALL_FORWARDING_TYPE_UNCONDITIONAL && > + sia[0] != '\0' && is_cfu_enabled(cf)) { > + g_dbus_send_message(conn, __ofono_error_not_available(msg)); > + > + return TRUE; > + } > + > cf->ss_req = g_try_new0(struct cf_ss_request, 1); > > if (cf->ss_req == NULL) { However, I think we should leave this part out. The supplementary service control path is almost a back door directly to the network, so if the input is valid it should go through to the driver. This is why interrogation is performed here regardless of whether the CACHED flag is set. Regards, -Denis From denkenz at gmail.com Wed Feb 22 05:19:24 2012 From: denkenz at gmail.com (Denis Kenzior) Date: Wed, 22 Feb 2012 07:19:24 -0600 Subject: [PATCHv2 4/8] call-forwarding: Don't report conditional cfs when cfu is active In-Reply-To: <1328531641-10612-5-git-send-email-oleg.zhurakivskyy@intel.com> References: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> <1328531641-10612-5-git-send-email-oleg.zhurakivskyy@intel.com> Message-ID: <4F44EB5C.4050908@gmail.com> Hi Oleg, On 02/06/2012 06:33 AM, Oleg Zhurakivskyy wrote: > --- > src/call-forwarding.c | 20 +++++++++++++++++--- > 1 files changed, 17 insertions(+), 3 deletions(-) > Patch has been applied, thanks. Regards, -Denis From denkenz at gmail.com Wed Feb 22 05:19:42 2012 From: denkenz at gmail.com (Denis Kenzior) Date: Wed, 22 Feb 2012 07:19:42 -0600 Subject: [PATCHv2 5/8] call-forwarding: Emit signals to mask/unmask conditional cfs In-Reply-To: <1328531641-10612-6-git-send-email-oleg.zhurakivskyy@intel.com> References: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> <1328531641-10612-6-git-send-email-oleg.zhurakivskyy@intel.com> Message-ID: <4F44EB6E.5040204@gmail.com> Hi Oleg, On 02/06/2012 06:33 AM, Oleg Zhurakivskyy wrote: > Emit signals to mask/unmask conditional cfs on cfu > activation/deactivation. > --- > src/call-forwarding.c | 30 ++++++++++++++++++++++++++++++ > 1 files changed, 30 insertions(+), 0 deletions(-) > Patch has been applied, thanks. Regards, -Denis From denkenz at gmail.com Wed Feb 22 05:24:30 2012 From: denkenz at gmail.com (Denis Kenzior) Date: Wed, 22 Feb 2012 07:24:30 -0600 Subject: [PATCHv2 6/8] call-forwarding: Don't run conditional queries if cfu is active In-Reply-To: <1328531641-10612-7-git-send-email-oleg.zhurakivskyy@intel.com> References: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> <1328531641-10612-7-git-send-email-oleg.zhurakivskyy@intel.com> Message-ID: <4F44EC8E.90501@gmail.com> Hi Oleg, On 02/06/2012 06:33 AM, Oleg Zhurakivskyy wrote: > --- > src/call-forwarding.c | 18 +++++++++++------- > 1 files changed, 11 insertions(+), 7 deletions(-) > > diff --git a/src/call-forwarding.c b/src/call-forwarding.c > index 7b086e0..2813005 100644 > --- a/src/call-forwarding.c > +++ b/src/call-forwarding.c > @@ -584,20 +584,24 @@ static void get_query_cf_callback(const struct ofono_error *error, int total, > struct ofono_call_forwarding *cf = data; > > if (error->type == OFONO_ERROR_TYPE_NO_ERROR) { > - GSList *l; > - l = cf_cond_list_create(total, list); > + GSList *l = cf_cond_list_create(total, list); > + > set_new_cond_list(cf, cf->query_next, l); > > DBG("%s conditions:", cf_type_lut[cf->query_next]); > + > cf_cond_list_print(l); I separated out two above chunks as a separate patch and applied them, since they are just cleanup anyway. > + } > > - if (cf->query_next == CALL_FORWARDING_TYPE_NOT_REACHABLE) > + if ((is_cfu_enabled(cf) && > + cf->query_next == CALL_FORWARDING_TYPE_UNCONDITIONAL) || > + cf->query_next == CALL_FORWARDING_TYPE_NOT_REACHABLE) { > + > + if (error->type == OFONO_ERROR_TYPE_NO_ERROR) > cf->flags |= CALL_FORWARDING_FLAG_CACHED; > - } > > - if (cf->query_next == CALL_FORWARDING_TYPE_NOT_REACHABLE) { > - DBusMessage *reply = cf_get_properties_reply(cf->pending, cf); > - __ofono_dbus_pending_reply(&cf->pending, reply); > + __ofono_dbus_pending_reply(&cf->pending, > + cf_get_properties_reply(cf->pending, cf)); > return; > } > The rest is on the right track, however I don't think this really works in the case where CFU is set when the query is being performed for the first time. e.g. - GetProperties -> query all - CFU is set, so don't query conditionals (which is correct since they are useless) - CFU is removed -> conditionals need to be updated now since they don't reflect reality Regards, -Denis From denkenz at gmail.com Wed Feb 22 05:33:15 2012 From: denkenz at gmail.com (Denis Kenzior) Date: Wed, 22 Feb 2012 07:33:15 -0600 Subject: [PATCHv2 7/8] call-forwarding: Clear the conditional cache flag In-Reply-To: <1328531641-10612-8-git-send-email-oleg.zhurakivskyy@intel.com> References: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> <1328531641-10612-8-git-send-email-oleg.zhurakivskyy@intel.com> Message-ID: <4F44EE9B.8000407@gmail.com> Hi Oleg, On 02/06/2012 06:34 AM, Oleg Zhurakivskyy wrote: > If there is an successful attempt to deactivate conditional cf > while cfu is active, the conditional cache flag is cleared. > --- > src/call-forwarding.c | 8 ++++++++ > 1 files changed, 8 insertions(+), 0 deletions(-) > > diff --git a/src/call-forwarding.c b/src/call-forwarding.c > index 2813005..a38a743 100644 > --- a/src/call-forwarding.c > +++ b/src/call-forwarding.c > @@ -722,6 +722,14 @@ static void set_query_cf_callback(const struct ofono_error *error, int total, > DBG("%s conditions:", cf_type_lut[cf->query_next]); > cf_cond_list_print(l); > > + /* > + * If there is an successful attempt to deactivate conditional cf > + * while cfu is active, the conditional cache flag is cleared. > + */ > + if (cf->query_next != CALL_FORWARDING_TYPE_UNCONDITIONAL && > + is_cfu_enabled(cf)) > + cf->flags &= ~CALL_FORWARDING_FLAG_CACHED; > + > if (cf->query_next != cf->query_end) { > cf->query_next++; > set_query_next_cf_cond(cf); This would cause us to re-query everything, which is a bit wasteful. Also, you have to handle the same action that might occur during supplementary services path, e.g. the user might deactivate / erase a conditional service there (see cf_ss_control and cf_ss_control_callback). The DisableAll path also needs to be handled properly. Also, there is another path you need to take under consideration and that is the supplementary service interrogation path. That one can update conditional settings erroneously if CFU is active. See ss_set_query_cf_callback. We might need to track CFU and conditional caches separately to make things easier. Let me know if you have any questions. CallForwarding was one of the earliest implemented interfaces and turned out to be quite a bit more complicated than originally thought ;) Regards, -Denis From oleg.zhurakivskyy at intel.com Thu Feb 23 01:51:35 2012 From: oleg.zhurakivskyy at intel.com (Oleg Zhurakivskyy) Date: Thu, 23 Feb 2012 11:51:35 +0200 Subject: [PATCHv2 6/8] call-forwarding: Don't run conditional queries if cfu is active In-Reply-To: <4F44EC8E.90501@gmail.com> References: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> <1328531641-10612-7-git-send-email-oleg.zhurakivskyy@intel.com> <4F44EC8E.90501@gmail.com> Message-ID: <4F460C27.8040102@intel.com> Hello Denis, On 02/22/2012 03:24 PM, Denis Kenzior wrote: > The rest is on the right track, however I don't think this really works > in the case where CFU is set when the query is being performed for the > first time. > > e.g. > - GetProperties -> query all > - CFU is set, so don't query conditionals (which is correct since they > are useless) > - CFU is removed -> conditionals need to be updated now since they don't > reflect reality Thanks for the review and for pointing this out. I will check how this could be corrected. Regards, Oleg -- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki From oleg.zhurakivskyy at intel.com Thu Feb 23 01:52:04 2012 From: oleg.zhurakivskyy at intel.com (Oleg Zhurakivskyy) Date: Thu, 23 Feb 2012 11:52:04 +0200 Subject: [PATCHv2 7/8] call-forwarding: Clear the conditional cache flag In-Reply-To: <4F44EE9B.8000407@gmail.com> References: <1328531641-10612-1-git-send-email-oleg.zhurakivskyy@intel.com> <1328531641-10612-8-git-send-email-oleg.zhurakivskyy@intel.com> <4F44EE9B.8000407@gmail.com> Message-ID: <4F460C44.2000004@intel.com> Hello Denis, On 02/22/2012 03:33 PM, Denis Kenzior wrote: > This would cause us to re-query everything, which is a bit wasteful. > Also, you have to handle the same action that might occur during > supplementary services path, e.g. the user might deactivate / erase a > conditional service there (see cf_ss_control and > cf_ss_control_callback). The DisableAll path also needs to be handled > properly. > > Also, there is another path you need to take under consideration and > that is the supplementary service interrogation path. That one can > update conditional settings erroneously if CFU is active. See > ss_set_query_cf_callback. > > We might need to track CFU and conditional caches separately to make > things easier. Let me know if you have any questions. CallForwarding > was one of the earliest implemented interfaces and turned out to be > quite a bit more complicated than originally thought ;) Thanks for the help and ideas here. Let me check the supplementary services path and how to deal with the caching. I will prepare patches to address these. Regards, Oleg -- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki From puffy.taco at gmail.com Thu Feb 23 16:49:59 2012 From: puffy.taco at gmail.com (Mike) Date: Thu, 23 Feb 2012 18:49:59 -0600 Subject: LG VX8360 HFP non-compliance issue Message-ID: I'm getting weird behaviour from an LG VX8360, connected via bluetooth HFP. When the phone connects, I see a CallAdded signal go out over dbus, despite there being no call on the phone itself. You can see the signal below. The LineIdentification held the actual phone number of the phone, but I replaced it with "xxxxxxxxxx". I also copied in the initial RFCOMM communication. It looks to me like this phone does not comply with the HFP spec in that it returns an answer to AT+CLCC when there is no phone call present (and at that, an index of 0). It also happens that the status is a 6, which does not appear to be a valid status in HFPv1.5. This just happens to map to the enum CALL_STATUS_DISCONNECTED, but I'm guessing this was merely coincidence. Since the state is broadcast as disconnected, I can simply ignore it in my GUI application. However, I'm wondering if this is something that is better handled in the ofono side? Thanks, Mike signal sender=:1.0 -> dest=(null destination) serial=35 path=/hfp/F4FC32DD7E08_0025E5B340D9; interface=org.ofono.VoiceCallManager; member=CallAdded object path "/hfp/F4FC32DD7E08_0025E5B340D9/voicecall00" array [ dict entry( string "State" variant string "disconnected" ) dict entry( string "LineIdentification" variant string "xxxxxxxxxx" ) dict entry( string "Name" variant string "" ) dict entry( string "Multiparty" variant boolean false ) dict entry( string "RemoteHeld" variant boolean false ) dict entry( string "RemoteMultiparty" variant boolean false ) dict entry( string "Emergency" variant boolean false ) ] < RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 12 fcs 0x7f 0000: 41 54 2b 42 52 53 46 3d 31 31 38 0d AT+BRSF=118. > RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 0 fcs 0xb9 credits 10 > RFCOMM(d): UIH: cr 1 dlci 14 pf 0 ilen 14 fcs 0xa5 0000: 0d 0a 2b 42 52 53 46 3a 20 33 35 39 0d 0a ..+BRSF: 359.. > RFCOMM(d): UIH: cr 1 dlci 14 pf 0 ilen 6 fcs 0xa5 0000: 0d 0a 4f 4b 0d 0a ..OK.. < RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 10 fcs 0x7f 0000: 41 54 2b 43 49 4e 44 3d 3f 0d AT+CIND=?. > RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 132 fcs 0xb9 credits 1 0000: 0d 0a 2b 43 49 4e 44 3a 20 28 22 63 61 6c 6c 22 ..+CIND: ("call" 0010: 2c 28 30 2c 31 29 29 2c 28 22 63 61 6c 6c 73 65 ,(0,1)),("callse 0020: 74 75 70 22 2c 28 30 2d 33 29 29 2c 28 22 73 65 tup",(0-3)),("se 0030: 72 76 69 63 65 22 2c 28 30 2c 31 29 29 2c 28 22 rvice",(0,1)),(" 0040: 73 69 67 6e 61 6c 22 2c 28 30 2d 35 29 29 2c 28 signal",(0-5)),( 0050: 22 72 6f 61 6d 22 2c 28 30 2c 31 29 29 2c 28 22 "roam",(0,1)),(" 0060: 62 61 74 74 63 68 67 22 2c 28 30 2d 35 29 29 2c battchg",(0-5)), 0070: 28 22 63 61 6c 6c 68 65 6c 64 22 2c 28 30 2d 32 ("callheld",(0-2 0080: 29 29 0d 0a )).. > RFCOMM(d): UIH: cr 1 dlci 14 pf 0 ilen 6 fcs 0xa5 0000: 0d 0a 4f 4b 0d 0a ..OK.. < RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 9 fcs 0x7f 0000: 41 54 2b 43 49 4e 44 3f 0d AT+CIND?. > RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 24 fcs 0xb9 credits 1 0000: 0d 0a 2b 43 49 4e 44 3a 20 30 2c 30 2c 31 2c 33 ..+CIND: 0,0,1,3 0010: 2c 30 2c 35 2c 30 0d 0a ,0,5,0.. > RFCOMM(d): UIH: cr 1 dlci 14 pf 0 ilen 6 fcs 0xa5 0000: 0d 0a 4f 4b 0d 0a ..OK.. < RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 16 fcs 0x7f 0000: 41 54 2b 43 4d 45 52 3d 33 2c 30 2c 30 2c 31 0d AT+CMER=3,0,0,1. > RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 6 fcs 0xb9 credits 1 0000: 0d 0a 4f 4b 0d 0a ..OK.. < RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 10 fcs 0x7f 0000: 41 54 2b 43 48 4c 44 3d 3f 0d AT+CHLD=?. > RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 16 fcs 0xb9 credits 1 0000: 0d 0a 2b 43 48 4c 44 3a 20 28 31 2c 32 29 0d 0a ..+CHLD: (1,2).. > RFCOMM(d): UIH: cr 1 dlci 14 pf 0 ilen 6 fcs 0xa5 0000: 0d 0a 4f 4b 0d 0a ..OK.. > RFCOMM(d): UIH: cr 1 dlci 14 pf 0 ilen 11 fcs 0xa5 0000: 0d 0a 2b 56 47 53 3a 20 37 0d 0a ..+VGS: 7.. < RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 10 fcs 0x7f 0000: 41 54 2b 43 4d 45 45 3d 31 0d AT+CMEE=1. > 0000: 06 00 00 00 10 35 03 19 11 0b 00 f0 35 06 09 00 .....5......5... 0010: 01 09 00 09 00 ..... > RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 6 fcs 0xb9 credits 1 0000: 0d 0a 4f 4b 0d 0a ..OK.. < RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 10 fcs 0x7f 0000: 41 54 2b 43 4c 49 50 3d 31 0d AT+CLIP=1. < 0000: 07 00 00 00 1c 00 19 35 17 35 15 09 00 01 35 03 .......5.5....5. 0010: 19 11 0b 09 00 09 35 08 35 06 19 11 0d 09 01 02 ......5.5....... 0020: 00 . > RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 6 fcs 0xb9 credits 1 0000: 0d 0a 4f 4b 0d 0a ..OK.. < RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 10 fcs 0x7f 0000: 41 54 2b 43 43 57 41 3d 31 0d AT+CCWA=1. > RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 6 fcs 0xb9 credits 1 0000: 0d 0a 4f 4b 0d 0a ..OK.. < RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 9 fcs 0x7f 0000: 41 54 2b 43 49 4e 44 3f 0d AT+CIND?. > RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 24 fcs 0xb9 credits 1 0000: 0d 0a 2b 43 49 4e 44 3a 20 30 2c 30 2c 31 2c 33 ..+CIND: 0,0,1,3 0010: 2c 30 2c 35 2c 30 0d 0a ,0,5,0.. > RFCOMM(d): UIH: cr 1 dlci 14 pf 0 ilen 6 fcs 0xa5 0000: 0d 0a 4f 4b 0d 0a ..OK.. < RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 9 fcs 0x7f 0000: 41 54 2b 56 47 53 3d 37 0d AT+VGS=7. > RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 6 fcs 0xb9 credits 1 0000: 0d 0a 4f 4b 0d 0a ..OK.. < RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 9 fcs 0x7f 0000: 41 54 2b 56 47 4d 3d 37 0d AT+VGM=7. > 0000: 00 01 .. < 0000: 02 01 04 08 .... > RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 6 fcs 0xb9 credits 1 0000: 0d 0a 4f 4b 0d 0a ..OK.. < RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 8 fcs 0x7f 0000: 41 54 2b 43 4c 43 43 0d AT+CLCC. > 0000: 10 02 04 ... < 0000: 12 02 01 00 07 06 00 00 3f ff 02 40 ........?..@ > RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 35 fcs 0xb9 credits 1 0000: 0d 0a 2b 43 4c 43 43 3a 20 30 2c 30 2c 36 2c 30 ..+CLCC: 0,0,6,0 0010: 2c 30 2c 22 36 31 32 38 36 38 35 37 37 36 22 2c ,0,"xxxxxxxxxx", 0020: 30 0d 0a 0.. > RFCOMM(d): UIH: cr 1 dlci 14 pf 0 ilen 6 fcs 0xa5 0000: 0d 0a 4f 4b 0d 0a ..OK.. From jussi.kukkonen at intel.com Fri Feb 24 03:55:37 2012 From: jussi.kukkonen at intel.com (Jussi Kukkonen) Date: Fri, 24 Feb 2012 13:55:37 +0200 Subject: trying to understand context creation In-Reply-To: <4F44B31D.2050501@gmail.com> References: <4F43A43D.3020503@gmail.com> <4F44B31D.2050501@gmail.com> Message-ID: Hi Dennis, On Wed, Feb 22, 2012 at 11:19 AM, Denis Kenzior wrote: >>> And no, there is absolutely no way to know whether a given context >>> settings are valid, but a good indication would be that a context >>> activation fails. >> >> Aha... would you consider it a good/bad idea if a configuration UI >> activated/deactivated the context after modifications to check for >> this? This could be useful to say "We couldn't connect to the network >> with these settings, would you like try another configuration?" >> > > I'm generally in favor of not over-complicating this, but instead > relying on the provisioning data as much as possible. Well... we do that pretty well already, right? ofono autoconfigures if there's a single match for the MMC/MNC. If there are several matches, my 3G wizard consists of a single Dropdown list with the plans and a OK-button. I'm trying to improve the two problem cases: 1. user has to run 3G wizard and makes poor selections 2. There's a HW problem As far as I can see the only way to do that is to fail as early as possible. Currently we fail as late as possible and that's a confusing user experience. > Look at iOS for a > good example, the user doesn't have any UI to edit context settings, it > is all provisioned using carrier profiles. ?Granted, the provisioning > database in use is a little bit better than what > mobile-broadband-provider-info provides, so some way to manually enter > details would still be required in our case; however we should strive to > make this as rarely used as possible. > > What you suggest is a good idea, but might be overkill... Since we have to let the user make a choice on something he does not understand, I don't see good alternatives: currently we do the worst possible thing: claim that everything is ok (by accepting the APN settings and even showing the cellular service) and then later fail when connecting -- and user has absolutely no way of knowing what the failure was about*. I'll gladly take suggestions for simpler solutions that lead to a UI that isn't confusing when things go wrong. Jussi *) emphasized by https://bugs.meego.com/show_bug.cgi?id=24943: connman cell service state never seems to go to "failure". From jr_extern at vfnet.de Fri Feb 24 04:23:32 2012 From: jr_extern at vfnet.de (Jens Rehsack) Date: Fri, 24 Feb 2012 13:23:32 +0100 Subject: Introducing Jens Rehsack Message-ID: <4F478144.1010208@vfnet.de> Hi oFono community, before start to asking questions, I'd like to introduce myself and why I joined into the community. I'm hired by Vodafone Global (Vodafone Group Services GmbH) to assist there on some networking services, currently location services. One part of the job will be to work with oFono, using it, learn some work flows - and when possible - improving it. This part of the job will also include submitting patches. My technical background is system development on Unix and embedded systems, most times in wired networking and related protocols. Mobile protocols and standards are completely new to me and I'm not tightened into names, abbreviations and protocols related to mobile world. I hope I can learn quickly what I need to know to start practical things with oFono. Best regards, Jens From jr_extern at vfnet.de Fri Feb 24 05:29:57 2012 From: jr_extern at vfnet.de (Jens Rehsack) Date: Fri, 24 Feb 2012 14:29:57 +0100 Subject: Enhancing mmsd Message-ID: <4F4790D5.3040608@vfnet.de> Hi, as announced in my last mail, I'm here to work with + improve ofono and related software. My next task will be to implement an ofono plugin which handles some UPL push messages. Because there is only one "listener" at org.ofono.PushNotificationAgent possible, I see two and a half way to go on: 1) fork ofono-mmsd to handle more message types than mms (via plugins?) 1b) fork ofono-mmsd to handle only SUPL push messages 2) find a way for more listeners on push messages Any suggestions, preferred ways? Best regards and have a nice weekend, Jens From ronald.tessier at linux.intel.com Fri Feb 24 06:44:05 2012 From: ronald.tessier at linux.intel.com (Ronald Tessier) Date: Fri, 24 Feb 2012 15:44:05 +0100 Subject: Enhancing mmsd In-Reply-To: <4F4790D5.3040608@vfnet.de> References: <4F4790D5.3040608@vfnet.de> Message-ID: <4F47A235.40807@linux.intel.com> Hi Jens, On 02/24/2012 02:29 PM, Jens Rehsack wrote: > Hi, > > as announced in my last mail, I'm here to work with + improve ofono > and related software. > > My next task will be to implement an ofono plugin which handles some > UPL push messages. Because there is only one "listener" at > org.ofono.PushNotificationAgent possible, I see two and a half way > to go on: > > 1) fork ofono-mmsd to handle more message types than mms > (via plugins?) > 1b) fork ofono-mmsd to handle only SUPL push messages > 2) find a way for more listeners on push messages > > Any suggestions, preferred ways? > > Best regards and have a nice weekend, > Jens > I think there is a third way to do what you want : write a SUPL push message consumer as an mmsd plugin and not as an ofono plugin. Actually, mmsd already implements a WAP push message dispatch mechanism for other push message than MMS. To check if this fits your needs, please have a look at the consumer.txt documentation from mmsd/doc/. Best regards. Have a nice week-end, Ronald From denkenz at gmail.com Thu Feb 23 21:12:10 2012 From: denkenz at gmail.com (Denis Kenzior) Date: Thu, 23 Feb 2012 23:12:10 -0600 Subject: trying to understand context creation In-Reply-To: References: <4F43A43D.3020503@gmail.com> <4F44B31D.2050501@gmail.com> Message-ID: <4F471C2A.8070704@gmail.com> Hi Jussi, On 02/24/2012 05:55 AM, Jussi Kukkonen wrote: > Hi Dennis, > > On Wed, Feb 22, 2012 at 11:19 AM, Denis Kenzior wrote: >>>> And no, there is absolutely no way to know whether a given context >>>> settings are valid, but a good indication would be that a context >>>> activation fails. >>> >>> Aha... would you consider it a good/bad idea if a configuration UI >>> activated/deactivated the context after modifications to check for >>> this? This could be useful to say "We couldn't connect to the network >>> with these settings, would you like try another configuration?" >>> >> >> I'm generally in favor of not over-complicating this, but instead >> relying on the provisioning data as much as possible. > > Well... we do that pretty well already, right? ofono autoconfigures if > there's a single match for the MMC/MNC. If there are several matches, > my 3G wizard consists of a single Dropdown list with the plans and a > OK-button. > > I'm trying to improve the two problem cases: > 1. user has to run 3G wizard and makes poor selections > 2. There's a HW problem > As far as I can see the only way to do that is to fail as early as > possible. Currently we fail as late as possible and that's a confusing > user experience. > I don't see how you are ever going to fix the HW problem part with a better 3G settings wizard. If it doesn't work, no amount of helpful UIs will make it work. And if the user is entering information without good understanding of the questions he's answering then either the provisioning database needs to be updated or we should be asking better questions. Of course, preferably we shouldn't even ask the user any questions if possible ;) >> Look at iOS for a >> good example, the user doesn't have any UI to edit context settings, it >> is all provisioned using carrier profiles. Granted, the provisioning >> database in use is a little bit better than what >> mobile-broadband-provider-info provides, so some way to manually enter >> details would still be required in our case; however we should strive to >> make this as rarely used as possible. >> >> What you suggest is a good idea, but might be overkill... > > Since we have to let the user make a choice on something he does not > understand, I don't see good alternatives: currently we do the worst > possible thing: claim that everything is ok (by accepting the APN > settings and even showing the cellular service) and then later fail > when connecting -- and user has absolutely no way of knowing what the > failure was about*. I'll gladly take suggestions for simpler solutions > that lead to a UI that isn't confusing when things go wrong. > If the user doesn't understand the choices he's making, then no amount of helpful UIs will help here. Imagine you walk into a store with a very helpful salesman, unfortunately you're speaking a different language. If you don't have a very good idea of what you're looking for, there's nothing he can do to help you. My point here is that we should re-examine what we can do to make provisioning more fool proof, rather than trying to band-aid a settings UI that is inherently not understandable to anyone who isn't a GSM geek. Regards, -Denis From denkenz at gmail.com Thu Feb 23 21:20:44 2012 From: denkenz at gmail.com (Denis Kenzior) Date: Thu, 23 Feb 2012 23:20:44 -0600 Subject: LG VX8360 HFP non-compliance issue In-Reply-To: References: Message-ID: <4F471E2C.9020208@gmail.com> Hi Mike, On 02/23/2012 06:49 PM, Mike wrote: > I'm getting weird behaviour from an LG VX8360, connected via bluetooth > HFP. When the phone connects, I see a CallAdded signal go out over > dbus, despite there being no call on the phone itself. You can see > the signal below. The LineIdentification held the actual phone number > of the phone, but I replaced it with "xxxxxxxxxx". I also copied in > the initial RFCOMM communication. It looks to me like this phone does > not comply with the HFP spec in that it returns an answer to AT+CLCC > when there is no phone call present (and at that, an index of 0). It > also happens that the status is a 6, which does not appear to be a > valid status in HFPv1.5. This just happens to map to the enum > CALL_STATUS_DISCONNECTED, but I'm guessing this was merely > coincidence. Since the state is broadcast as disconnected, I can > simply ignore it in my GUI application. However, I'm wondering if > this is something that is better handled in the ofono side? > > Thanks, > Mike > Try the following patch. Regards, -Denis -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-atutil-Ignore-invalid-CLCC-results.patch URL: From jr_extern at vfnet.de Fri Feb 24 07:17:13 2012 From: jr_extern at vfnet.de (Jens Rehsack) Date: Fri, 24 Feb 2012 16:17:13 +0100 Subject: Enhancing mmsd In-Reply-To: <4F47A235.40807@linux.intel.com> References: <4F4790D5.3040608@vfnet.de> <4F47A235.40807@linux.intel.com> Message-ID: <4F47A9F9.7010407@vfnet.de> Am 24.02.2012 15:44, schrieb Ronald Tessier: > Hi Jens, > > On 02/24/2012 02:29 PM, Jens Rehsack wrote: >> Hi, >> >> as announced in my last mail, I'm here to work with + improve ofono >> and related software. >> >> My next task will be to implement an ofono plugin which handles some >> UPL push messages. Because there is only one "listener" at >> org.ofono.PushNotificationAgent possible, I see two and a half way >> to go on: >> >> 1) fork ofono-mmsd to handle more message types than mms >> (via plugins?) >> 1b) fork ofono-mmsd to handle only SUPL push messages >> 2) find a way for more listeners on push messages >> >> Any suggestions, preferred ways? > > I think there is a third way to do what you want : write a SUPL push > message consumer as an mmsd plugin and not as an ofono plugin. Actually, > mmsd already implements a WAP push message dispatch mechanism for other > push message than MMS. > To check if this fits your needs, please have a look at the consumer.txt > documentation from mmsd/doc/. Yeah, you're right. I read it on my first day and had it totally forgotten meanwhile. Initially it confuses me, because I assumed there can be embedded documents in an mms - and didn't recognize that mms is the built-in plugin for mmsd - which should be renamed into wspd ;) So my proposal 1 is already done - but I was to much confused to recognize it. Thanks to point me on it. Best regards, Jens From jussi.kukkonen at intel.com Fri Feb 24 08:13:23 2012 From: jussi.kukkonen at intel.com (Jussi Kukkonen) Date: Fri, 24 Feb 2012 18:13:23 +0200 Subject: trying to understand context creation In-Reply-To: <4F471C2A.8070704@gmail.com> References: <4F43A43D.3020503@gmail.com> <4F44B31D.2050501@gmail.com> <4F471C2A.8070704@gmail.com> Message-ID: On Fri, Feb 24, 2012 at 7:12 AM, Denis Kenzior wrote: >> I'm trying to improve the two problem cases: >> ?1. user has to run 3G wizard and makes poor selections >> ?2. There's a HW problem >> As far as I can see the only way to do that is to fail as early as >> possible. Currently we fail as late as possible and that's a confusing >> user experience. > > I don't see how you are ever going to fix the HW problem part with a > better 3G settings wizard. ?If it doesn't work, no amount of helpful UIs > will make it work. User experience issues have more shades of grey than middleware issues... Failing early and clearly is significantly better UX than failing but leading the user to believe things work. I'm not "fixing" HW problems any more than I'm "fixing" connman crashes in my UI -- both are still events I'd rather handle (witihin limits) if that makes the UX better. > And if the user is entering information without good understanding of > the questions he's answering then either the provisioning database needs > to be updated or we should be asking better questions. > > Of course, preferably we shouldn't even ask the user any questions if > possible ;) We are in total agreement. I will gladly remove this whole UI when you or someone else with knowledge on this tells me that ofono + mbpi can handle things. Likewise, if you tell me I can drop the manual settings part and that won't harm many users, I will do it in a heart beat. >>> Look at iOS for a >>> good example, the user doesn't have any UI to edit context settings, it >>> is all provisioned using carrier profiles. ?Granted, the provisioning >>> database in use is a little bit better than what >>> mobile-broadband-provider-info provides, so some way to manually enter >>> details would still be required in our case; however we should strive to >>> make this as rarely used as possible. >>> >>> What you suggest is a good idea, but might be overkill... >> >> Since we have to let the user make a choice on something he does not >> understand, I don't see good alternatives: currently we do the worst >> possible thing: claim that everything is ok (by accepting the APN >> settings and even showing the cellular service) and then later fail >> when connecting -- and user has absolutely no way of knowing what the >> failure was about*. I'll gladly take suggestions for simpler solutions >> that lead to a UI that isn't confusing when things go wrong. >> > > If the user doesn't understand the choices he's making, then no amount > of helpful UIs will help here. ?Imagine you walk into a store with a > very helpful salesman, unfortunately you're speaking a different > language. ?If you don't have a very good idea of what you're looking > for, there's nothing he can do to help you. > > My point here is that we should re-examine what we can do to make > provisioning more fool proof, rather than trying to band-aid a settings > UI that is inherently not understandable to anyone who isn't a GSM geek. Yes, we should. As upstream project developers we have the luxury of making statements like that (you here, I can do it in dawati-shell) and that is definitely what actually improves the whole stack in the long term. Unfortunately I also have a role closer to an actual product where "yeah, the provisioning should be better" is not an acceptable answer to a bug report about the connectivity UI. My job is to make the UI work as well as it can with the middleware and provisining db we have right now. You can call it band-aiding but it's still my job. - Jussi From denkenz at gmail.com Thu Feb 23 23:20:59 2012 From: denkenz at gmail.com (Denis Kenzior) Date: Fri, 24 Feb 2012 01:20:59 -0600 Subject: trying to understand context creation In-Reply-To: References: <4F43A43D.3020503@gmail.com> <4F44B31D.2050501@gmail.com> <4F471C2A.8070704@gmail.com> Message-ID: <4F473A5B.8040202@gmail.com> Hi Jussi, > User experience issues have more shades of grey than middleware > issues... Failing early and clearly is significantly better UX than > failing but leading the user to believe things work. I'm not "fixing" UI has more shades of grey than a telephony stack? That is an argument we should have over beer sometime ;) > HW problems any more than I'm "fixing" connman crashes in my UI -- > both are still events I'd rather handle (witihin limits) if that makes > the UX better. > Sure, the UI should handle the basics, e.g. connman service being stopped by the administrator. However, going out of your way to 'handle' connman crashes or ofono HW issues is clearly the wrong thing to do. A system service crashing is a major problem and should be addressed by the project responsible, not by the UI. > We are in total agreement. I will gladly remove this whole UI when you > or someone else with knowledge on this tells me that ofono + mbpi can > handle things. Likewise, if you tell me I can drop the manual settings > part and that won't harm many users, I will do it in a heart beat. > I would guesstimate that it works in 90% of the cases today, the other 5-9% are handled using a simple dialog. If this is not the case, then we would like to know what is failing / not working. Dropping the settings UI is probably never going to be feasible, but it should be made into an avenue of last resort. E.g. something that the user can be guided through by tech support at the carrier for instance. Not something that the user should ever see under 99% of circumstances. >> My point here is that we should re-examine what we can do to make >> provisioning more fool proof, rather than trying to band-aid a settings >> UI that is inherently not understandable to anyone who isn't a GSM geek. > > Yes, we should. As upstream project developers we have the luxury of > making statements like that (you here, I can do it in dawati-shell) > and that is definitely what actually improves the whole stack in the > long term. Please don't make this an upstream vs downstream issue. It is not. Nobody is knocking what you're trying to do, just disagreeing on the approach ;) > > Unfortunately I also have a role closer to an actual product where > "yeah, the provisioning should be better" is not an acceptable answer > to a bug report about the connectivity UI. My job is to make the UI > work as well as it can with the middleware and provisining db we have > right now. You can call it band-aiding but it's still my job. You are spending time optimizing the 1-5% case, clearly something is wrong here. If provisioning isn't working properly then we should fix it in either oFono or MBPI. And there's always the option of using another provisioning database for the carriers being targeted for our products... Regards, -Denis From neil at ossau.homelinux.net Sun Feb 26 09:43:56 2012 From: neil at ossau.homelinux.net (Neil Jerram) Date: Sun, 26 Feb 2012 17:43:56 +0000 Subject: [PATCH] hso: Don't access freed data, in hso_set_online Message-ID: <1330278236-1335-1-git-send-email-neil@ossau.homelinux.net> --- plugins/hso.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/plugins/hso.c b/plugins/hso.c index 4834c56..697beaa 100644 --- a/plugins/hso.c +++ b/plugins/hso.c @@ -422,7 +422,7 @@ static void hso_set_online(struct ofono_modem *modem, ofono_bool_t online, g_free(cbd); - CALLBACK_WITH_FAILURE(cb, cbd->data); + CALLBACK_WITH_FAILURE(cb, user_data); } static void hso_pre_sim(struct ofono_modem *modem) -- 1.7.9 From marcel at holtmann.org Sun Feb 26 18:07:28 2012 From: marcel at holtmann.org (Marcel Holtmann) Date: Sun, 26 Feb 2012 18:07:28 -0800 Subject: [PATCH] hso: Don't access freed data, in hso_set_online In-Reply-To: <1330278236-1335-1-git-send-email-neil@ossau.homelinux.net> References: <1330278236-1335-1-git-send-email-neil@ossau.homelinux.net> Message-ID: <1330308448.3392.14.camel@aeonflux> Hi Neil, > plugins/hso.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/plugins/hso.c b/plugins/hso.c > index 4834c56..697beaa 100644 > --- a/plugins/hso.c > +++ b/plugins/hso.c > @@ -422,7 +422,7 @@ static void hso_set_online(struct ofono_modem *modem, ofono_bool_t online, > > g_free(cbd); > > - CALLBACK_WITH_FAILURE(cb, cbd->data); > + CALLBACK_WITH_FAILURE(cb, user_data); > } just put the g_free last. See plugins/ifx.c for example. It seems I fixed most of the plugins, but forgot this one. Regards Marcel From marcel at holtmann.org Sun Feb 26 18:14:44 2012 From: marcel at holtmann.org (Marcel Holtmann) Date: Sun, 26 Feb 2012 18:14:44 -0800 Subject: Enhancing mmsd In-Reply-To: <4F47A9F9.7010407@vfnet.de> References: <4F4790D5.3040608@vfnet.de> <4F47A235.40807@linux.intel.com> <4F47A9F9.7010407@vfnet.de> Message-ID: <1330308884.3392.18.camel@aeonflux> Hi Jens, > >> as announced in my last mail, I'm here to work with + improve ofono > >> and related software. > >> > >> My next task will be to implement an ofono plugin which handles some > >> UPL push messages. Because there is only one "listener" at > >> org.ofono.PushNotificationAgent possible, I see two and a half way > >> to go on: > >> > >> 1) fork ofono-mmsd to handle more message types than mms > >> (via plugins?) > >> 1b) fork ofono-mmsd to handle only SUPL push messages > >> 2) find a way for more listeners on push messages > >> > >> Any suggestions, preferred ways? > > > > I think there is a third way to do what you want : write a SUPL push > > message consumer as an mmsd plugin and not as an ofono plugin. Actually, > > mmsd already implements a WAP push message dispatch mechanism for other > > push message than MMS. > > To check if this fits your needs, please have a look at the consumer.txt > > documentation from mmsd/doc/. > > Yeah, you're right. I read it on my first day and had it totally > forgotten meanwhile. Initially it confuses me, because I assumed > there can be embedded documents in an mms - and didn't recognize > that mms is the built-in plugin for mmsd - which should be renamed > into wspd ;) we actually discussed this initially to create a separate WAP push handler daemon, but reality is that it is really pointless and pretty wasteful as a separate daemon. The heavy lifting part is parsing WSP and that is the majority of what mmsd is doing anyway already. So it is cheaper to just have one MMS daemon that includes WAP Push handling. So essentially you get the MMS handling for free with it. Regards Marcel From marcel at holtmann.org Sun Feb 26 18:15:42 2012 From: marcel at holtmann.org (Marcel Holtmann) Date: Sun, 26 Feb 2012 18:15:42 -0800 Subject: Introducing Jens Rehsack In-Reply-To: <4F478144.1010208@vfnet.de> References: <4F478144.1010208@vfnet.de> Message-ID: <1330308942.3392.19.camel@aeonflux> Hi Jens, > before start to asking questions, I'd like to introduce myself and > why I joined into the community. > > I'm hired by Vodafone Global (Vodafone Group Services GmbH) to > assist there on some networking services, currently location > services. One part of the job will be to work with oFono, using > it, learn some work flows - and when possible - improving it. > This part of the job will also include submitting patches. very much welcome and looking forward to patches from you. Regards Marcel From r.r.zaripov at gmail.com Sun Feb 26 23:19:43 2012 From: r.r.zaripov at gmail.com (r.r.zaripov at gmail.com) Date: Mon, 27 Feb 2012 11:19:43 +0400 Subject: [PATCH 1/2] sim900: Add support for SIMCOM SMS delivery reports Message-ID: <1330327184-1497-1-git-send-email-r.r.zaripov@gmail.com> From: Renat Zaripov --- plugins/sim900.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/plugins/sim900.c b/plugins/sim900.c index f7b1642..b2d1b46 100644 --- a/plugins/sim900.c +++ b/plugins/sim900.c @@ -224,7 +224,8 @@ static void sim900_post_sim(struct ofono_modem *modem) DBG("%p", modem); ofono_phonebook_create(modem, 0, "atmodem", data->modem); - ofono_sms_create(modem, 0, "atmodem", data->modem); + ofono_sms_create(modem, OFONO_VENDOR_SIMCOM, "atmodem", + data->modem); } static void sim900_post_online(struct ofono_modem *modem) -- 1.7.7.3 From r.r.zaripov at gmail.com Sun Feb 26 23:19:44 2012 From: r.r.zaripov at gmail.com (r.r.zaripov at gmail.com) Date: Mon, 27 Feb 2012 11:19:44 +0400 Subject: [PATCH 2/2] sim900: Disable sending AT+CNMA In-Reply-To: <1330327184-1497-1-git-send-email-r.r.zaripov@gmail.com> References: <1330327184-1497-1-git-send-email-r.r.zaripov@gmail.com> Message-ID: <1330327184-1497-2-git-send-email-r.r.zaripov@gmail.com> From: Renat Zaripov SIMCOM SIM900 modem module not support AT+CNMA command --- drivers/atmodem/sms.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/atmodem/sms.c b/drivers/atmodem/sms.c index c6fb8c4..c31eb39 100644 --- a/drivers/atmodem/sms.c +++ b/drivers/atmodem/sms.c @@ -389,6 +389,7 @@ static void at_cds_notify(GAtResult *result, gpointer user_data) static void at_cmt_notify(GAtResult *result, gpointer user_data) { struct ofono_sms *sms = user_data; + struct sms_data *data = ofono_sms_get_data(sms); const char *hexpdu; long pdu_len; int tpdu_len; @@ -409,7 +410,8 @@ static void at_cmt_notify(GAtResult *result, gpointer user_data) decode_hex_own_buf(hexpdu, -1, &pdu_len, 0, pdu); ofono_sms_deliver_notify(sms, pdu, pdu_len, tpdu_len); - at_ack_delivery(sms); + if (data->vendor != OFONO_VENDOR_SIMCOM) + at_ack_delivery(sms); } static void at_cmgr_notify(GAtResult *result, gpointer user_data) -- 1.7.7.3 From jr_extern at vfnet.de Mon Feb 27 01:21:15 2012 From: jr_extern at vfnet.de (Jens Rehsack) Date: Mon, 27 Feb 2012 10:21:15 +0100 Subject: [PATCH] add some length verification to avoid reading not owned memory Message-ID: <4F4B4B0B.7060606@vfnet.de> Hi, while reading mmsd sources I stumbled over missing length checks in src/push.c:mms_push_notify(). I didn't re-read the entire source to prove overall ;) Best regards, Jens -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-add-some-length-verification-to-avoid-reading-not-ow.patch Type: text/x-patch Size: 1350 bytes Desc: not available URL: From jussi.kukkonen at intel.com Mon Feb 27 01:25:03 2012 From: jussi.kukkonen at intel.com (Jussi Kukkonen) Date: Mon, 27 Feb 2012 11:25:03 +0200 Subject: trying to understand context creation In-Reply-To: <4F473A5B.8040202@gmail.com> References: <4F43A43D.3020503@gmail.com> <4F44B31D.2050501@gmail.com> <4F471C2A.8070704@gmail.com> <4F473A5B.8040202@gmail.com> Message-ID: On Fri, Feb 24, 2012 at 9:20 AM, Denis Kenzior wrote: >> HW problems any more than I'm "fixing" connman crashes in my UI -- >> both are still events I'd rather handle (witihin limits) if that makes >> the UX better. > > Sure, the UI should handle the basics, e.g. connman service being > stopped by the administrator. ?However, going out of your way to > 'handle' connman crashes or ofono HW issues is clearly the wrong thing > to do. ?A system service crashing is a major problem and should be > addressed by the project responsible, not by the UI. >From a UI point of view, connman crashing and connman being stopped are 100% same -- the only thing the UI can do is inform the user that there is a critical problem, so they won't just wait there expecting that Wifi AP to show up any moment now... I hope the users would never have to see that but they sometimes do. I'm not sure what you mean by "going out of my way". I either handle this situation or I don't. The same goes for ofono contexts that are, from my POV, broken. >> We are in total agreement. I will gladly remove this whole UI when you >> or someone else with knowledge on this tells me that ofono + mbpi can >> handle things. Likewise, if you tell me I can drop the manual settings >> part and that won't harm many users, I will do it in a heart beat. >> > > I would guesstimate that it works in 90% of the cases today, the other > 5-9% are handled using a simple dialog. ?If this is not the case, then > we would like to know what is failing / not working. > > Dropping the settings UI is probably never going to be feasible, but it > should be made into an avenue of last resort. ?E.g. something that the > user can be guided through by tech support at the carrier for instance. > ?Not something that the user should ever see under 99% of circumstances. Let's work on this then -- that is my goal as well, but my understanding of current situation was just way grimmer: maybe I've missed some bit about how the provisioning works. This is my understanding: * connman shows a cellular service for every internet context * ofono creates a internet context for every modem that is capable * if there are multiple APNs defined in mbpi for the carrier, the ofono context will be empy * mbpi has lots and lots of carriers with multiple APNs, most of the big names I checked seem to have multiple ones. This seems to imply that by far the most common use case is this: * user plugs in a new modem * ofono creates an empty context (because of multiple APNs defined for carrier) * connman shows a broken cellular service that does absolutely nothing -- it stays in "idle" forever and does not react to anything. You said 90% of the cases should just work -- where does this difference in experiences come from? - Jussi From marcel at holtmann.org Mon Feb 27 02:54:09 2012 From: marcel at holtmann.org (Marcel Holtmann) Date: Mon, 27 Feb 2012 02:54:09 -0800 Subject: trying to understand context creation In-Reply-To: References: <4F43A43D.3020503@gmail.com> <4F44B31D.2050501@gmail.com> <4F471C2A.8070704@gmail.com> <4F473A5B.8040202@gmail.com> Message-ID: <1330340049.3392.43.camel@aeonflux> Hi Jussi, > >> HW problems any more than I'm "fixing" connman crashes in my UI -- > >> both are still events I'd rather handle (witihin limits) if that makes > >> the UX better. > > > > Sure, the UI should handle the basics, e.g. connman service being > > stopped by the administrator. However, going out of your way to > > 'handle' connman crashes or ofono HW issues is clearly the wrong thing > > to do. A system service crashing is a major problem and should be > > addressed by the project responsible, not by the UI. > > From a UI point of view, connman crashing and connman being stopped > are 100% same -- the only thing the UI can do is inform the user that > there is a critical problem, so they won't just wait there expecting > that Wifi AP to show up any moment now... I hope the users would never > have to see that but they sometimes do. I would do this centralized with a system that monitors systemd status and make sure that systemd restarts ConnMan properly. So that even if something goes wrong, the user never really sees this. Unless it is like a real fatal problem. But trying to handle this different than a restart of ConnMan is kinda weird. I would not even bother. Especially since there is nothing you can do about it anyway. > I'm not sure what you mean by "going out of my way". I either handle > this situation or I don't. The same goes for ofono contexts that are, > from my POV, broken. Why are they broken again? > >> We are in total agreement. I will gladly remove this whole UI when you > >> or someone else with knowledge on this tells me that ofono + mbpi can > >> handle things. Likewise, if you tell me I can drop the manual settings > >> part and that won't harm many users, I will do it in a heart beat. > >> > > > > I would guesstimate that it works in 90% of the cases today, the other > > 5-9% are handled using a simple dialog. If this is not the case, then > > we would like to know what is failing / not working. > > > > Dropping the settings UI is probably never going to be feasible, but it > > should be made into an avenue of last resort. E.g. something that the > > user can be guided through by tech support at the carrier for instance. > > Not something that the user should ever see under 99% of circumstances. > > Let's work on this then -- that is my goal as well, but my > understanding of current situation was just way grimmer: maybe I've > missed some bit about how the provisioning works. This is my > understanding: > * connman shows a cellular service for every internet context > * ofono creates a internet context for every modem that is capable > * if there are multiple APNs defined in mbpi for the carrier, the > ofono context will be empy > * mbpi has lots and lots of carriers with multiple APNs, most of the > big names I checked seem to have multiple ones. > > This seems to imply that by far the most common use case is this: > * user plugs in a new modem > * ofono creates an empty context (because of multiple APNs defined > for carrier) > * connman shows a broken cellular service that does absolutely > nothing -- it stays in "idle" forever and does not react to anything. > > You said 90% of the cases should just work -- where does this > difference in experiences come from? As pointed out by Denis, the automated setup experience can only be as good as your database. However it is not our job to install or create the perfect APN list. That is an OEMs job and it depends on what kind of quality and experience they wanna have. Problem is that MBPI needs to be clearly improved. It is currently a dumping ground for random information. And btw. neither Apple nor Android gets this fully right. I have an ICS that keep resetting the APN configuration as TIM Italy while network is Wind in Canada. So if you really care about ConnMan showing an empty cellular service, then we can talk about adapting ConnMan to not bother showing that service if the APN is empty. Regards Marcel From jussi.kukkonen at intel.com Mon Feb 27 05:20:45 2012 From: jussi.kukkonen at intel.com (Jussi Kukkonen) Date: Mon, 27 Feb 2012 15:20:45 +0200 Subject: trying to understand context creation In-Reply-To: <1330340049.3392.43.camel@aeonflux> References: <4F43A43D.3020503@gmail.com> <4F44B31D.2050501@gmail.com> <4F471C2A.8070704@gmail.com> <4F473A5B.8040202@gmail.com> <1330340049.3392.43.camel@aeonflux> Message-ID: On Mon, Feb 27, 2012 at 12:54 PM, Marcel Holtmann wrote: >> From a UI point of view, connman crashing and connman being stopped >> are 100% same -- the only thing the UI can do is inform the user that >> there is a critical ?problem, so they won't just wait there expecting >> that Wifi AP to show up any moment now... I hope the users would never >> have to see that but they sometimes do. > > I would do this centralized with a system that monitors systemd status > and make sure that systemd restarts ConnMan properly. So that even if > something goes wrong, the user never really sees this. Unless it is like > a real fatal problem. > > But trying to handle this different than a restart of ConnMan is kinda > weird. I would not even bother. Especially since there is nothing you > can do about it anyway. I was maybe not clear enough. I only handle the case of connman disappearing from the bus. And by "handle" I mean "tell the user there is a problem". To be extra clear: I do not try to restart connman or ofono or anything stupid like that, I totally realize that's not for my component to do. The only thing I want to is to prevent user confusion about what they can do or cannot do at specific times. Exactly the same thing that I want to do when e.g. cellular services aren't appearing as expected or when they fail. >> I'm not sure what you mean by "going out of my way". I either handle >> this situation or I don't. The same goes for ofono contexts that are, >> from my POV, broken. > > Why are they broken again? I'm referring to the empty contexts I mentioned below. They are what I believe most ofono+mbpi users will get at the moment, and as far as I can tell they are useless, if not broken. >> >> We are in total agreement. I will gladly remove this whole UI when you >> >> or someone else with knowledge on this tells me that ofono + mbpi can >> >> handle things. Likewise, if you tell me I can drop the manual settings >> >> part and that won't harm many users, I will do it in a heart beat. >> >> >> > >> > I would guesstimate that it works in 90% of the cases today, the other >> > 5-9% are handled using a simple dialog. ?If this is not the case, then >> > we would like to know what is failing / not working. >> > >> > Dropping the settings UI is probably never going to be feasible, but it >> > should be made into an avenue of last resort. ?E.g. something that the >> > user can be guided through by tech support at the carrier for instance. >> > ?Not something that the user should ever see under 99% of circumstances. >> >> Let's work on this then -- that is my goal as well, but my >> understanding of current situation was just way grimmer: maybe I've >> missed some bit about how the provisioning works. This is my >> understanding: >> ? * connman shows a cellular service for every internet context >> ? * ofono creates a internet context for every modem that is capable >> ? * if there are multiple APNs defined in mbpi for the carrier, the >> ofono context will be empy >> ? * mbpi has lots and lots of carriers with multiple APNs, most of the >> big names I checked seem to have multiple ones. >> >> This seems to imply that by far the most common use case is this: >> ? * user plugs in a new modem >> ? * ofono creates an empty context (because of multiple APNs defined >> for carrier) >> ? * connman shows a broken cellular service that does absolutely >> nothing -- it stays in "idle" forever and does not react to anything. >> >> You said 90% of the cases should just work -- where does this >> difference in experiences come from? > > As pointed out by Denis, the automated setup experience can only be as > good as your database. However it is not our job to install or create > the perfect APN list. That is an OEMs job and it depends on what kind of > quality and experience they wanna have. I understand this. I still have to provide a UI that works with the middleware we have and the mbpi we have. > Problem is that MBPI needs to be clearly improved. It is currently a > dumping ground for random information. And btw. neither Apple nor > Android gets this fully right. I have an ICS that keep resetting the APN > configuration as TIM Italy while network is Wind in Canada. > > So if you really care about ConnMan showing an empty cellular service, > then we can talk about adapting ConnMan to not bother showing that > service if the APN is empty. I still feel like I must be missing something: you seem to imply that I should _not_ care about connman showing a non-working cellular service that appears to most cellular users? I don't think that is a real option. If we have a way to make this work for ~95% of users -- yeah, I do want to do that. Not showing a service for empty internet contexts would seem to go a long way towards that goal, so I would be very happy with that. - Jussi From jr_extern at vfnet.de Mon Feb 27 07:17:32 2012 From: jr_extern at vfnet.de (Jens Rehsack) Date: Mon, 27 Feb 2012 16:17:32 +0100 Subject: [PATCH] configure/make basics Message-ID: <4F4B9E8C.3080809@vfnet.de> Hi, while hacking on a plugin for mmsd to deal with supl push messages, I ran into a few "not so nice" solved things in configure.ac / Makefile.am 1) libtool handling libtool configuration is meanwhile done using LT_INIT(options) instead of AC_PROC_LIBTOOL and alike ==> because of libtool stores some of the configuration in the generated libtool shell script, it's reasonable to run LT_INIT as late as possible (painfully learned while writing and porting c++ software for many OS) 2) additional libraries do no require explicit libraries (like -lresolv), always let a devop in doubt invoke configure with LIBS="-lmyspecialwrapper" to wrap between available libs/functions and requirements See pkgsrc's nbcompat library for example Best regards, Jens -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-changing-depreciated-libtool-initialization-to-moder.patch Type: text/x-patch Size: 1649 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-let-configure-find-required-libs.patch Type: text/x-patch Size: 2413 bytes Desc: not available URL: From marcel at holtmann.org Mon Feb 27 09:22:19 2012 From: marcel at holtmann.org (Marcel Holtmann) Date: Mon, 27 Feb 2012 09:22:19 -0800 Subject: [PATCH] add some length verification to avoid reading not owned memory In-Reply-To: <4F4B4B0B.7060606@vfnet.de> References: <4F4B4B0B.7060606@vfnet.de> Message-ID: <1330363339.3392.52.camel@aeonflux> Hi Jens, > while reading mmsd sources I stumbled over missing length > checks in src/push.c:mms_push_notify(). I didn't re-read > the entire source to prove overall ;) please use git format-patch and git send-email to send us inline patches. In case your email client doesn't support inline patches nicely. Reviewing patches that are attached is super painful and in most cases they get ignored then. Regards Marcel From marcel at holtmann.org Mon Feb 27 09:23:31 2012 From: marcel at holtmann.org (Marcel Holtmann) Date: Mon, 27 Feb 2012 09:23:31 -0800 Subject: [PATCH] configure/make basics In-Reply-To: <4F4B9E8C.3080809@vfnet.de> References: <4F4B9E8C.3080809@vfnet.de> Message-ID: <1330363411.3392.53.camel@aeonflux> Hi Jens, > while hacking on a plugin for mmsd to deal with supl push > messages, I ran into a few "not so nice" solved things > in configure.ac / Makefile.am > > 1) libtool handling > libtool configuration is meanwhile done using LT_INIT(options) > instead of AC_PROC_LIBTOOL and alike > ==> because of libtool stores some of the configuration > in the generated libtool shell script, it's reasonable > to run LT_INIT as late as possible (painfully learned > while writing and porting c++ software for many OS) > 2) additional libraries > do no require explicit libraries (like -lresolv), always > let a devop in doubt invoke configure with > LIBS="-lmyspecialwrapper" to wrap between available > libs/functions and requirements > See pkgsrc's nbcompat library for example one patch per email please and all inline. Thanks. Regards Marcel From marcel at holtmann.org Mon Feb 27 09:30:30 2012 From: marcel at holtmann.org (Marcel Holtmann) Date: Mon, 27 Feb 2012 09:30:30 -0800 Subject: trying to understand context creation In-Reply-To: References: <4F43A43D.3020503@gmail.com> <4F44B31D.2050501@gmail.com> <4F471C2A.8070704@gmail.com> <4F473A5B.8040202@gmail.com> <1330340049.3392.43.camel@aeonflux> Message-ID: <1330363830.3392.59.camel@aeonflux> Hi Jussi, > >> From a UI point of view, connman crashing and connman being stopped > >> are 100% same -- the only thing the UI can do is inform the user that > >> there is a critical problem, so they won't just wait there expecting > >> that Wifi AP to show up any moment now... I hope the users would never > >> have to see that but they sometimes do. > > > > I would do this centralized with a system that monitors systemd status > > and make sure that systemd restarts ConnMan properly. So that even if > > something goes wrong, the user never really sees this. Unless it is like > > a real fatal problem. > > > > But trying to handle this different than a restart of ConnMan is kinda > > weird. I would not even bother. Especially since there is nothing you > > can do about it anyway. > > I was maybe not clear enough. I only handle the case of connman > disappearing from the bus. And by "handle" I mean "tell the user there > is a problem". I am not sure even that is a good idea. I would expect just systemd to restart connmand right away and you could just go on with it, but fair enough. > To be extra clear: I do not try to restart connman or ofono or > anything stupid like that, I totally realize that's not for my > component to do. The only thing I want to is to prevent user confusion > about what they can do or cannot do at specific times. Exactly the > same thing that I want to do when e.g. cellular services aren't > appearing as expected or when they fail. > > >> I'm not sure what you mean by "going out of my way". I either handle > >> this situation or I don't. The same goes for ofono contexts that are, > >> from my POV, broken. > > > > Why are they broken again? > > I'm referring to the empty contexts I mentioned below. They are what I > believe most ofono+mbpi users will get at the moment, and as far as I > can tell they are useless, if not broken. The initial context is actually there to make it a lot easier for the UI to handle the APN setup. And checking for an empty APN is a fair thing to do. If MBPI does not give us useful information, we are kinda screwed. And btw. the database/provision support in oFono is pluggable. We do not have to use MBPI. It is just that nobody else has bothered to create something better. > >> >> We are in total agreement. I will gladly remove this whole UI when you > >> >> or someone else with knowledge on this tells me that ofono + mbpi can > >> >> handle things. Likewise, if you tell me I can drop the manual settings > >> >> part and that won't harm many users, I will do it in a heart beat. > >> >> > >> > > >> > I would guesstimate that it works in 90% of the cases today, the other > >> > 5-9% are handled using a simple dialog. If this is not the case, then > >> > we would like to know what is failing / not working. > >> > > >> > Dropping the settings UI is probably never going to be feasible, but it > >> > should be made into an avenue of last resort. E.g. something that the > >> > user can be guided through by tech support at the carrier for instance. > >> > Not something that the user should ever see under 99% of circumstances. > >> > >> Let's work on this then -- that is my goal as well, but my > >> understanding of current situation was just way grimmer: maybe I've > >> missed some bit about how the provisioning works. This is my > >> understanding: > >> * connman shows a cellular service for every internet context > >> * ofono creates a internet context for every modem that is capable > >> * if there are multiple APNs defined in mbpi for the carrier, the > >> ofono context will be empy > >> * mbpi has lots and lots of carriers with multiple APNs, most of the > >> big names I checked seem to have multiple ones. > >> > >> This seems to imply that by far the most common use case is this: > >> * user plugs in a new modem > >> * ofono creates an empty context (because of multiple APNs defined > >> for carrier) > >> * connman shows a broken cellular service that does absolutely > >> nothing -- it stays in "idle" forever and does not react to anything. > >> > >> You said 90% of the cases should just work -- where does this > >> difference in experiences come from? > > > > As pointed out by Denis, the automated setup experience can only be as > > good as your database. However it is not our job to install or create > > the perfect APN list. That is an OEMs job and it depends on what kind of > > quality and experience they wanna have. > > I understand this. > > I still have to provide a UI that works with the middleware we have > and the mbpi we have. Maybe at this point it is time to provide something better than MBPI, but that is out of the scope for oFono actually. > > Problem is that MBPI needs to be clearly improved. It is currently a > > dumping ground for random information. And btw. neither Apple nor > > Android gets this fully right. I have an ICS that keep resetting the APN > > configuration as TIM Italy while network is Wind in Canada. > > > > So if you really care about ConnMan showing an empty cellular service, > > then we can talk about adapting ConnMan to not bother showing that > > service if the APN is empty. > > I still feel like I must be missing something: you seem to imply that > I should _not_ care about connman showing a non-working cellular > service that appears to most cellular users? I don't think that is a > real option. > > If we have a way to make this work for ~95% of users -- yeah, I do > want to do that. Not showing a service for empty internet contexts > would seem to go a long way towards that goal, so I would be very > happy with that. As I said, we can just make ConnMan not show that service if the APN setting from oFono is empty. Care to provide a patch for that? Regards Marcel From neil at ossau.homelinux.net Mon Feb 27 11:59:32 2012 From: neil at ossau.homelinux.net (Neil Jerram) Date: Mon, 27 Feb 2012 19:59:32 +0000 Subject: [PATCH] hso: Don't access freed data, in hso_set_online In-Reply-To: <1330308448.3392.14.camel@aeonflux> (Marcel Holtmann's message of "Sun, 26 Feb 2012 18:07:28 -0800") References: <1330278236-1335-1-git-send-email-neil@ossau.homelinux.net> <1330308448.3392.14.camel@aeonflux> Message-ID: <874nucgi8r.fsf@neil-laptop.ossau.uklinux.net> Marcel Holtmann writes: > Hi Neil, > >> plugins/hso.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/plugins/hso.c b/plugins/hso.c >> index 4834c56..697beaa 100644 >> --- a/plugins/hso.c >> +++ b/plugins/hso.c >> @@ -422,7 +422,7 @@ static void hso_set_online(struct ofono_modem *modem, ofono_bool_t online, >> >> g_free(cbd); >> >> - CALLBACK_WITH_FAILURE(cb, cbd->data); >> + CALLBACK_WITH_FAILURE(cb, user_data); >> } > > just put the g_free last. See plugins/ifx.c for example. It seems I > fixed most of the plugins, but forgot this one. OK, will do, thanks. Neil From neil at ossau.homelinux.net Mon Feb 27 12:04:43 2012 From: neil at ossau.homelinux.net (Neil Jerram) Date: Mon, 27 Feb 2012 20:04:43 +0000 Subject: [PATCH] hso: Don't access freed data, in hso_set_online Message-ID: <1330373083-1223-1-git-send-email-neil@ossau.homelinux.net> --- plugins/hso.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/plugins/hso.c b/plugins/hso.c index 497c64e..249bb2c 100644 --- a/plugins/hso.c +++ b/plugins/hso.c @@ -421,9 +421,9 @@ static void hso_set_online(struct ofono_modem *modem, ofono_bool_t online, if (g_at_chat_send(chat, command, NULL, set_online_cb, cbd, g_free)) return; - g_free(cbd); - CALLBACK_WITH_FAILURE(cb, cbd->data); + + g_free(cbd); } static void hso_pre_sim(struct ofono_modem *modem) -- 1.7.9 From neil at ossau.homelinux.net Mon Feb 27 14:24:31 2012 From: neil at ossau.homelinux.net (Neil Jerram) Date: Mon, 27 Feb 2012 22:24:31 +0000 Subject: HSO modem, apparent confusion between App and Control ports Message-ID: <87r4xfgbj4.fsf@neil-laptop.ossau.uklinux.net> I'm using an HSO modem in a GTA04 device, and have a UI that, on session startup, powers the modem on, and sets it online. Sometimes - after roughly 50% of reboots - the setting online times out, and I've established that this is because there's still a preceding command in chat->command_queue, when hso_set_online() is called. So the real problem is that the preceding AT command appears to the code not to have completed. I've looked at the logs and identified a significant-looking difference between a good run and a bad one. In a good run, the ofonod log (following powering on), leading up to the point of divergence, has: Feb 27 22:01:59 gta04 daemon.info ofonod[983]: Control: > AT_OERCN?\r Feb 27 22:01:59 gta04 daemon.info ofonod[983]: Control: < \r\n_OERCN: 3, 10\r\n\r\nOK\r\n Feb 27 22:01:59 gta04 daemon.debug ofonod[983]: drivers/atmodem/sim.c:oercn_cb() retry counter id=1, val=3 Feb 27 22:01:59 gta04 daemon.debug ofonod[983]: drivers/atmodem/sim.c:oercn_cb() retry counter id=9, val=10 Feb 27 22:01:59 gta04 daemon.info ofonod[983]: Control: > AT+CRSM=192,28590\r Feb 27 22:02:00 gta04 daemon.info ofonod[983]: Control: < \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n Feb 27 22:02:00 gta04 daemon.info ofonod[983]: Control: > AT+CRSM=176,28589,0,0,4\r Feb 27 22:02:00 gta04 daemon.info ofonod[983]: Control: < \r\n+CRSM: 144,0,"00FFFF02"\r\n\r\nOK\r\n Feb 27 22:02:00 gta04 daemon.debug ofonod[983]: drivers/atmodem/sim.c:at_crsm_read_cb() crsm_read_cb: 90, 00, 4 Feb 27 22:02:00 gta04 daemon.debug ofonod[983]: src/simfs.c:sim_fs_op_read_block_cb() bufoff: 0, dataoff: 0, tocopy: 4 Feb 27 22:02:00 gta04 daemon.info ofonod[983]: Control: > AT+CRSM=192,28438\r Feb 27 22:02:00 gta04 daemon.info ofonod[983]: Control: < \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n But in a bad run, the last line is different: Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: > AT_OERCN?\r Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: < \r\n_OERCN: 3, 10\r\n\r\nOK\r\n Feb 27 21:52:33 gta04 daemon.debug ofonod[996]: drivers/atmodem/sim.c:oercn_cb() retry counter id=1, val=3 Feb 27 21:52:33 gta04 daemon.debug ofonod[996]: drivers/atmodem/sim.c:oercn_cb() retry counter id=9, val=10 Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: > AT+CRSM=192,28590\r Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: < \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: > AT+CRSM=176,28589,0,0,4\r Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: < \r\n+CRSM: 144,0,"00FFFF02"\r\n\r\nOK\r\n Feb 27 21:52:33 gta04 daemon.debug ofonod[996]: drivers/atmodem/sim.c:at_crsm_read_cb() crsm_read_cb: 90, 00, 4 Feb 27 21:52:33 gta04 daemon.debug ofonod[996]: src/simfs.c:sim_fs_op_read_block_cb() bufoff: 0, dataoff: 0, tocopy: 4 Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: > AT+CRSM=192,28438\r Feb 27 21:52:34 gta04 daemon.info ofonod[996]: App: < \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n\r\n_OSIGQ: 0,0\r\n\r\n+CREG: 0\r\n\r\n+CGREG: 0\r\n\r\n_OSSYSI: 3\r\n I.e. firstly the AT+CRSM reply appears to be on the wrong channel, and secondly it seems to have a whole load of further replies or unsolicited indications tacked on. If the problem isn't already obvious, from the above, can you advise what more I can do to debug or fix this? It seems clear that the above is wrong, but I don't yet understand ofono well enough to have a clue what the right fix might be. Thanks, Neil From marcel at holtmann.org Mon Feb 27 15:17:41 2012 From: marcel at holtmann.org (Marcel Holtmann) Date: Mon, 27 Feb 2012 15:17:41 -0800 Subject: [PATCH] hso: Don't access freed data, in hso_set_online In-Reply-To: <1330373083-1223-1-git-send-email-neil@ossau.homelinux.net> References: <1330373083-1223-1-git-send-email-neil@ossau.homelinux.net> Message-ID: <1330384661.3392.71.camel@aeonflux> Hi Neil, > --- > plugins/hso.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) patch has been applied. Thanks. Regards Marcel From marcel at holtmann.org Mon Feb 27 22:21:10 2012 From: marcel at holtmann.org (Marcel Holtmann) Date: Mon, 27 Feb 2012 22:21:10 -0800 Subject: [Gta04-owner] HSO modem, apparent confusion between App and Control ports In-Reply-To: <87r4xfgbj4.fsf@neil-laptop.ossau.uklinux.net> References: <87r4xfgbj4.fsf@neil-laptop.ossau.uklinux.net> Message-ID: <1330410070.3392.78.camel@aeonflux> Hi Neil, > I'm using an HSO modem in a GTA04 device, and have a UI that, on session > startup, powers the modem on, and sets it online. > > Sometimes - after roughly 50% of reboots - the setting online times out, > and I've established that this is because there's still a preceding > command in chat->command_queue, when hso_set_online() is called. So the > real problem is that the preceding AT command appears to the code not to > have completed. > > I've looked at the logs and identified a significant-looking difference > between a good run and a bad one. In a good run, the ofonod log > (following powering on), leading up to the point of divergence, has: > > Feb 27 22:01:59 gta04 daemon.info ofonod[983]: Control: > AT_OERCN?\r > Feb 27 22:01:59 gta04 daemon.info ofonod[983]: Control: < \r\n_OERCN: 3, 10\r\n\r\nOK\r\n > Feb 27 22:01:59 gta04 daemon.debug ofonod[983]: drivers/atmodem/sim.c:oercn_cb() retry counter id=1, val=3 > Feb 27 22:01:59 gta04 daemon.debug ofonod[983]: drivers/atmodem/sim.c:oercn_cb() retry counter id=9, val=10 > Feb 27 22:01:59 gta04 daemon.info ofonod[983]: Control: > AT+CRSM=192,28590\r > Feb 27 22:02:00 gta04 daemon.info ofonod[983]: Control: < \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n > Feb 27 22:02:00 gta04 daemon.info ofonod[983]: Control: > AT+CRSM=176,28589,0,0,4\r > Feb 27 22:02:00 gta04 daemon.info ofonod[983]: Control: < \r\n+CRSM: 144,0,"00FFFF02"\r\n\r\nOK\r\n > Feb 27 22:02:00 gta04 daemon.debug ofonod[983]: drivers/atmodem/sim.c:at_crsm_read_cb() crsm_read_cb: 90, 00, 4 > Feb 27 22:02:00 gta04 daemon.debug ofonod[983]: src/simfs.c:sim_fs_op_read_block_cb() bufoff: 0, dataoff: 0, tocopy: 4 > Feb 27 22:02:00 gta04 daemon.info ofonod[983]: Control: > AT+CRSM=192,28438\r > Feb 27 22:02:00 gta04 daemon.info ofonod[983]: Control: < \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n > > But in a bad run, the last line is different: > > Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: > AT_OERCN?\r > Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: < \r\n_OERCN: 3, 10\r\n\r\nOK\r\n > Feb 27 21:52:33 gta04 daemon.debug ofonod[996]: drivers/atmodem/sim.c:oercn_cb() retry counter id=1, val=3 > Feb 27 21:52:33 gta04 daemon.debug ofonod[996]: drivers/atmodem/sim.c:oercn_cb() retry counter id=9, val=10 > Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: > AT+CRSM=192,28590\r > Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: < \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n > Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: > AT+CRSM=176,28589,0,0,4\r > Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: < \r\n+CRSM: 144,0,"00FFFF02"\r\n\r\nOK\r\n > Feb 27 21:52:33 gta04 daemon.debug ofonod[996]: drivers/atmodem/sim.c:at_crsm_read_cb() crsm_read_cb: 90, 00, 4 > Feb 27 21:52:33 gta04 daemon.debug ofonod[996]: src/simfs.c:sim_fs_op_read_block_cb() bufoff: 0, dataoff: 0, tocopy: 4 > Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: > AT+CRSM=192,28438\r > Feb 27 21:52:34 gta04 daemon.info ofonod[996]: App: < \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n\r\n_OSIGQ: 0,0\r\n\r\n+CREG: 0\r\n\r\n+CGREG: 0\r\n\r\n_OSSYSI: 3\r\n > > I.e. firstly the AT+CRSM reply appears to be on the wrong channel, and > secondly it seems to have a whole load of further replies or unsolicited > indications tacked on. if this happens, then this modem is seriously broken. Such a broken behavior will causes the AT chat handler to fail and there is nothing you can do to restore it into a proper state. Try to put the SIM atom onto the application port and see if that helps a bit to make this reliable. @@ -435,7 +435,7 @@ static void hso_pre_sim(struct ofono_modem *modem) ofono_devinfo_create(modem, 0, "atmodem", data->control); sim = ofono_sim_create(modem, OFONO_VENDOR_OPTION_HSO, - "atmodem", data->control); + "atmodem", data->app); Regards Marcel From jr_extern at vfnet.de Tue Feb 28 00:17:23 2012 From: jr_extern at vfnet.de (jr_extern at vfnet.de) Date: Tue, 28 Feb 2012 09:17:23 +0100 Subject: [PATCH 1/3] add some length verification to avoid reading not owned memory Message-ID: <1330417045-26518-1-git-send-email-jr_extern@vfnet.de> From: Jens Rehsack --- src/push.c | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/src/push.c b/src/push.c index 6a54907..6107352 100644 --- a/src/push.c +++ b/src/push.c @@ -351,13 +351,16 @@ gboolean mms_push_notify(unsigned char *pdu, unsigned int len, /* Consume TID and Type */ nread = 2; - if (wsp_decode_uintvar(pdu + nread, len, + if (wsp_decode_uintvar(pdu + nread, len - nread, &headerslen, &consumed) == FALSE) return FALSE; /* Consume uintvar bytes */ nread += consumed; + /* Check if content type could be read */ + if (headerslen > (len - nread)) + return FALSE; /* Try to decode content-type */ if (wsp_decode_content_type(pdu + nread, headerslen, &ct, &consumed, ¶m_len) == FALSE) @@ -370,6 +373,9 @@ gboolean mms_push_notify(unsigned char *pdu, unsigned int len, consumed += param_len; nread += consumed; + /* Check if application_id could be read */ + if ((headerslen - consumed) > (len - nread)) + return FALSE; /* Parse header to decode application_id */ wsp_header_iter_init(&iter, pdu + nread, headerslen - consumed, 0); -- 1.7.9.1 From jr_extern at vfnet.de Tue Feb 28 00:17:24 2012 From: jr_extern at vfnet.de (jr_extern at vfnet.de) Date: Tue, 28 Feb 2012 09:17:24 +0100 Subject: [PATCH 2/3] changing depreciated libtool initialization to modern one In-Reply-To: <1330417045-26518-1-git-send-email-jr_extern@vfnet.de> References: <1330417045-26518-1-git-send-email-jr_extern@vfnet.de> Message-ID: <1330417045-26518-2-git-send-email-jr_extern@vfnet.de> From: Jens Rehsack --- Makefile.am | 4 ++++ configure.ac | 10 ++++++++-- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/Makefile.am b/Makefile.am index c3a4486..bebcb90 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1,6 +1,10 @@ AM_MAKEFLAGS = --no-print-directory +LIBTOOL_DEPS = @LIBTOOL_DEPS@ +libtool: $(LIBTOOL_DEPS) + $(SHELL) ./config.status libtool + gdbus_sources = gdbus/gdbus.h gdbus/mainloop.c gdbus/watch.c \ gdbus/object.c gdbus/polkit.c diff --git a/configure.ac b/configure.ac index 34cc526..d82569b 100644 --- a/configure.ac +++ b/configure.ac @@ -31,8 +31,8 @@ AC_PROG_INSTALL m4_define([_LT_AC_TAGCONFIG], []) m4_ifdef([AC_LIBTOOL_TAGS], [AC_LIBTOOL_TAGS([])]) -AC_DISABLE_STATIC -AC_PROG_LIBTOOL +dnl AC_DISABLE_STATIC +dnl AC_PROG_LIBTOOL AC_ARG_ENABLE(optimization, AC_HELP_STRING([--disable-optimization], [disable code optimization through compiler]), [ @@ -58,6 +58,12 @@ AC_ARG_ENABLE(pie, AC_HELP_STRING([--enable-pie], fi ]) +dnl LT_INIT should be invoked after all compiler flags checks, because +dnl of LT_INIT remembers the RPATH stored in test targets which might +dnl be different for different compiler flags (known issue on AIX) +LT_INIT([dlopen,disable-static]) +AC_SUBST([LIBTOOL_DEPS]) + AC_CHECK_HEADERS(resolv.h, dummy=yes, AC_MSG_ERROR(resolver header files are required)) AC_CHECK_LIB(resolv, ns_initparse, dummy=yes, [ -- 1.7.9.1 From jr_extern at vfnet.de Tue Feb 28 00:17:25 2012 From: jr_extern at vfnet.de (jr_extern at vfnet.de) Date: Tue, 28 Feb 2012 09:17:25 +0100 Subject: [PATCH 3/3] let configure find required libs In-Reply-To: <1330417045-26518-1-git-send-email-jr_extern@vfnet.de> References: <1330417045-26518-1-git-send-email-jr_extern@vfnet.de> Message-ID: <1330417045-26518-3-git-send-email-jr_extern@vfnet.de> From: Jens Rehsack --- Makefile.am | 2 +- configure.ac | 24 +++++++++++++++++------- 2 files changed, 18 insertions(+), 8 deletions(-) diff --git a/Makefile.am b/Makefile.am index bebcb90..178def4 100644 --- a/Makefile.am +++ b/Makefile.am @@ -28,7 +28,7 @@ src_mmsd_SOURCES = $(gdbus_sources) $(gweb_sources) $(builtin_sources) \ src/push.h src/push.c src/store.h src/store.c \ src/wsputil.h src/wsputil.c src/mmsutil.h src/mmsutil.c -src_mmsd_LDADD = $(builtin_libadd) @GLIB_LIBS@ @DBUS_LIBS@ -lresolv -ldl +src_mmsd_LDADD = $(builtin_libadd) @GLIB_LIBS@ @DBUS_LIBS@ src_mmsd_LDFLAGS = -Wl,--export-dynamic diff --git a/configure.ac b/configure.ac index d82569b..883b59c 100644 --- a/configure.ac +++ b/configure.ac @@ -64,15 +64,25 @@ dnl be different for different compiler flags (known issue on AIX) LT_INIT([dlopen,disable-static]) AC_SUBST([LIBTOOL_DEPS]) +dnl check how we can use the resolver. while resolv.h comes with bind, +dnl it's probably reasonable to use a combined search macro like +dnl smart-snmpd's ACX_CHECK_LIB_FLAGS AC_CHECK_HEADERS(resolv.h, dummy=yes, AC_MSG_ERROR(resolver header files are required)) -AC_CHECK_LIB(resolv, ns_initparse, dummy=yes, [ - AC_CHECK_LIB(resolv, __ns_initparse, dummy=yes, - AC_MSG_ERROR(resolver library support is required)) -]) - -AC_CHECK_LIB(dl, dlopen, dummy=yes, - AC_MSG_ERROR(dynamic linking loader is required)) +dnl ns_initparse is libresolv internal use only - limited usage intended? +AC_SEARCH_LIBS(ns_initparse, resolv, , + AC_MSG_ERROR(resolver support is required)) +dnl AC_CHECK_LIB(resolv, ns_initparse, dummy=yes, [ +dnl AC_CHECK_LIB(resolv, __ns_initparse, dummy=yes, +dnl AC_MSG_ERROR(resolver library support is required)) +dnl ]) + +dnl search how we can load dynamic libraries +dnl TODO use libltdl, which would work on BeOS (Haiku), Darwin (MacOS X) or +dnl for debugging purposes with libtool's dlpreopen +AC_SEARCH_LIBS(dlopen, dl, , AC_MSG_ERROR(dynamic linking loader is required)) +dnl AC_CHECK_LIB(dl, dlopen, dummy=yes, +dnl AC_MSG_ERROR(dynamic linking loader is required)) PKG_CHECK_MODULES(GLIB, glib-2.0 >= 2.16, dummy=yes, AC_MSG_ERROR(GLib >= 2.16 is required)) -- 1.7.9.1 From jr_extern at vfnet.de Tue Feb 28 00:30:17 2012 From: jr_extern at vfnet.de (Jens Rehsack) Date: Tue, 28 Feb 2012 09:30:17 +0100 Subject: [PATCH] add some length verification to avoid reading not owned memory In-Reply-To: <1330363339.3392.52.camel@aeonflux> References: <4F4B4B0B.7060606@vfnet.de> <1330363339.3392.52.camel@aeonflux> Message-ID: <4F4C9099.7070609@vfnet.de> Am 27.02.2012 18:22, schrieb Marcel Holtmann: > Hi Jens, Hi Marcel, >> while reading mmsd sources I stumbled over missing length >> checks in src/push.c:mms_push_notify(). I didn't re-read >> the entire source to prove overall ;) > > please use git format-patch and git send-email to send us inline > patches. In case your email client doesn't support inline patches > nicely. Well, inline patches aren't requested at http://ofono.org/wiki/ofono-etiquette. You probably should do. > Reviewing patches that are attached is super painful and in most > cases they get ignored then. Well, my mail client (Thunderbird) and most modern clients I know are able to show attached files of text/x-patch (and similar) type. OTOH I wonder why you want to review patches in your mail client. Wouldn't it much better to use a specialized too which highlights the changes like $ gvim "+vert diffpatch " $ emacs or $ xfdiff ? Don't you have to save the patch files in such cases anyway? Best regards, Jens From wagi at monom.org Tue Feb 28 01:19:23 2012 From: wagi at monom.org (Daniel Wagner) Date: Tue, 28 Feb 2012 10:19:23 +0100 Subject: [RFC v0] ofono: Only register network when APN is set In-Reply-To: <1330363830.3392.59.camel@aeonflux> References: <1330363830.3392.59.camel@aeonflux> Message-ID: <1330420763-8244-1-git-send-email-wagi@monom.org> From: Daniel Wagner We should now show a network without an APN. --- I have not tested this one. But something like this should do the trick. Maybe someone with deeper knowledge on the APN behavior could explain under which circumstances the APN is set, e.g. see the netreg vs apn setting in this patch. Not sure if this is correct. cheers, daniel plugins/ofono.c | 25 +++++++++++++++++++++++++ 1 files changed, 25 insertions(+), 0 deletions(-) diff --git a/plugins/ofono.c b/plugins/ofono.c index d87d7b6..c92c3cc 100644 --- a/plugins/ofono.c +++ b/plugins/ofono.c @@ -105,6 +105,9 @@ enum ofono_api { * the plugin about IP configuration through the updating the context's * properties. * + * The network is only registered at the core when the AccessPointName + * has been set. + * * CDMA working flow: * * When a new modem appears, the plugin always powers it up. This @@ -172,6 +175,7 @@ struct modem_data { /* ConnectionContext Interface */ connman_bool_t active; connman_bool_t set_active; + char *apn; /* SimManager Interface */ char *imsi; @@ -1105,6 +1109,10 @@ static int add_cm_context(struct modem_data *modem, const char *context_path, dbus_message_iter_get_basic(&value, &active); DBG("%s Active %d", modem->path, active); + } else if (g_str_equal(key, "AccessPointName") == TRUE) { + dbus_message_iter_get_basic(&value, &modem->apn); + + DBG("%s AccessPointName %s", modem->path, modem->apn); } dbus_message_iter_next(dict); @@ -1180,6 +1188,19 @@ static gboolean context_changed(DBusConnection *connection, set_connected(modem); else set_disconnected(modem); + } else if (g_str_equal(key, "AccessPointName") == TRUE) { + g_free(modem->apn); + + dbus_message_iter_get_basic(&value, &modem->apn); + + DBG("%s AccessPointName %s", modem->path, modem->apn); + + if (has_interface(modem->interfaces, + OFONO_API_NETREG) == TRUE && + modem->network != NULL) { + DBG("Register network at core"); + add_network(modem); + } } return TRUE; @@ -1518,6 +1539,9 @@ static void netreg_properties_reply(struct modem_data *modem, return; } + if (modem->apn == NULL) + return; + add_network(modem); if (modem->active == TRUE) @@ -2187,6 +2211,7 @@ static void remove_modem(gpointer data) g_free(modem->serial); g_free(modem->name); g_free(modem->imsi); + g_free(modem->apn); g_free(modem->path); g_free(modem); -- 1.7.9.48.g85da4d From wagi at monom.org Tue Feb 28 02:02:30 2012 From: wagi at monom.org (Daniel Wagner) Date: Tue, 28 Feb 2012 11:02:30 +0100 Subject: [RFC v0] ofono: Only register network when APN is set In-Reply-To: <1330420763-8244-1-git-send-email-wagi@monom.org> References: <1330363830.3392.59.camel@aeonflux> <1330420763-8244-1-git-send-email-wagi@monom.org> Message-ID: <4F4CA636.2000503@monom.org> O> dbus_message_iter_next(dict); > @@ -1180,6 +1188,19 @@ static gboolean context_changed(DBusConnection *connection, > set_connected(modem); > else > set_disconnected(modem); > + } else if (g_str_equal(key, "AccessPointName") == TRUE) { > + g_free(modem->apn); > + > + dbus_message_iter_get_basic(&value, &modem->apn); > + > + DBG("%s AccessPointName %s", modem->path, modem->apn); > + > + if (has_interface(modem->interfaces, > + OFONO_API_NETREG) == TRUE && > + modem->network != NULL) { > + DBG("Register network at core"); > + add_network(modem); > + } that should be a "modem->network == NULL" of course. From frederic.danis at linux.intel.com Tue Feb 28 05:33:57 2012 From: frederic.danis at linux.intel.com (=?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Danis?=) Date: Tue, 28 Feb 2012 14:33:57 +0100 Subject: [PATCH] emulator: Fix for PTS test TC_AG_TWC_BV_02_I Message-ID: <1330436037-18377-1-git-send-email-frederic.danis@linux.intel.com> RING event should only be sent when callsetup indicator is set to Incoming and there is no active call. If call indicator is set to inactive while callsetup is already set to Incoming (waiting call has generated +CCWA), RING event should be sent after all calls' state have been updated. As state of calls are updated one by one, generating multiple calls to ofono_emulator_set_indicator(), do not call notify_ring() just after call indicator went from active/held to inactive (only start ring timer). In ring_timer(), in case of a call in waiting state, just exit and wait for next timeout. --- src/emulator.c | 21 +++++++++++---------- 1 files changed, 11 insertions(+), 10 deletions(-) diff --git a/src/emulator.c b/src/emulator.c index 262e782..fed699c 100644 --- a/src/emulator.c +++ b/src/emulator.c @@ -414,6 +414,13 @@ static gboolean notify_ring(void *user_data) if (em->type == OFONO_EMULATOR_TYPE_HFP && em->slc == FALSE) return TRUE; + /* + * In case of waiting call becoming an incoming call, call status + * change may not have been done yet, wait for change has been completed + */ + if (find_call_with_status(em, CALL_STATUS_WAITING)) + return TRUE; + g_at_server_send_unsolicited(em->server, "RING"); if (!em->clip) @@ -421,13 +428,6 @@ static gboolean notify_ring(void *user_data) c = find_call_with_status(em, CALL_STATUS_INCOMING); - /* - * In case of waiting call becoming an incoming call, call status - * change may not have been done yet, so try to find waiting call too - */ - if (c == NULL) - c = find_call_with_status(em, CALL_STATUS_WAITING); - if (c == NULL) return TRUE; @@ -1221,10 +1221,10 @@ void ofono_emulator_set_indicator(struct ofono_emulator *em, /* * Ring timer should be started when: * - callsetup indicator is set to Incoming and there is no active call - * (not a waiting call) + * (not a waiting call), in this case, a first RING should be sent + * just after the +CIEV * - or call indicator is set to inactive while callsetup is already * set to Incoming. - * In those cases, a first RING should be sent just after the +CIEV * Ring timer should be stopped for all other values of callsetup */ if (waiting) @@ -1247,8 +1247,9 @@ void ofono_emulator_set_indicator(struct ofono_emulator *em, return; } -start_ring: notify_ring(em); + +start_ring: em->callsetup_source = g_timeout_add_seconds(RING_TIMEOUT, notify_ring, em); } -- 1.7.1 From jussi.kukkonen at intel.com Tue Feb 28 06:06:17 2012 From: jussi.kukkonen at intel.com (Jussi Kukkonen) Date: Tue, 28 Feb 2012 16:06:17 +0200 Subject: [RFC v0] ofono: Only register network when APN is set In-Reply-To: <1330420763-8244-1-git-send-email-wagi@monom.org> References: <1330363830.3392.59.camel@aeonflux> <1330420763-8244-1-git-send-email-wagi@monom.org> Message-ID: On Tue, Feb 28, 2012 at 11:19 AM, Daniel Wagner wrote: > From: Daniel Wagner > > We should now show a network without an APN. > --- > I have not tested this one. But something like this should do > the trick. Maybe someone with deeper knowledge on the APN > behavior could explain under which circumstances the APN is set, e.g. > see the netreg vs apn setting in this patch. Not sure if this is correct. > > cheers, > daniel Thanks Daniel. This sort of works after some fixes but it looks like there are still issues if modem or context properties change. I'll have a go a fixing it later today. I'm including my initial comments below for reference (just in case I don't manage to fix them). Also while I remember: cm_context_added() does a lookup on modem_hash when it probably shoud use context_hash. I'll include this in the patches. > ?plugins/ofono.c | ? 25 +++++++++++++++++++++++++ > ?1 files changed, 25 insertions(+), 0 deletions(-) > > diff --git a/plugins/ofono.c b/plugins/ofono.c > index d87d7b6..c92c3cc 100644 > --- a/plugins/ofono.c > +++ b/plugins/ofono.c > @@ -105,6 +105,9 @@ enum ofono_api { > ?* the plugin about IP configuration through the updating the context's > ?* properties. > ?* > + * The network is only registered at the core when the AccessPointName > + * has been set. > + * > ?* CDMA working flow: > ?* > ?* When a new modem appears, the plugin always powers it up. This > @@ -172,6 +175,7 @@ struct modem_data { > ? ? ? ?/* ConnectionContext Interface */ > ? ? ? ?connman_bool_t active; > ? ? ? ?connman_bool_t set_active; > + ? ? ? char *apn; probably makes sense to have this in network_context -- easier to keep them in sync if e.g. context disappears. > > ? ? ? ?/* SimManager Interface */ > ? ? ? ?char *imsi; > @@ -1105,6 +1109,10 @@ static int add_cm_context(struct modem_data *modem, const char *context_path, > ? ? ? ? ? ? ? ? ? ? ? ?dbus_message_iter_get_basic(&value, &active); > > ? ? ? ? ? ? ? ? ? ? ? ?DBG("%s Active %d", modem->path, active); > + ? ? ? ? ? ? ? } else if (g_str_equal(key, "AccessPointName") == TRUE) { > + ? ? ? ? ? ? ? ? ? ? ? dbus_message_iter_get_basic(&value, &modem->apn); copying needed. > + > + ? ? ? ? ? ? ? ? ? ? ? DBG("%s AccessPointName %s", modem->path, modem->apn); > ? ? ? ? ? ? ? ?} > > ? ? ? ? ? ? ? ?dbus_message_iter_next(dict); > @@ -1180,6 +1188,19 @@ static gboolean context_changed(DBusConnection *connection, > ? ? ? ? ? ? ? ? ? ? ? ?set_connected(modem); > ? ? ? ? ? ? ? ?else > ? ? ? ? ? ? ? ? ? ? ? ?set_disconnected(modem); > + ? ? ? } else if (g_str_equal(key, "AccessPointName") == TRUE) { > + ? ? ? ? ? ? ? g_free(modem->apn); > + > + ? ? ? ? ? ? ? dbus_message_iter_get_basic(&value, &modem->apn); > + > + ? ? ? ? ? ? ? DBG("%s AccessPointName %s", modem->path, modem->apn); copy needed as well > + > + ? ? ? ? ? ? ? if (has_interface(modem->interfaces, > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? OFONO_API_NETREG) == TRUE && > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? modem->network != NULL) { > + ? ? ? ? ? ? ? ? ? ? ? DBG("Register network at core"); > + ? ? ? ? ? ? ? ? ? ? ? add_network(modem); > + ? ? ? ? ? ? ? } * if a network exists and apn is empty -> remove_network() * if a network does not exist and netreg iface is supported and apn is not empty -> add_network() also, probably need to call set_connected() if Active is set? > ? ? ? ?} > > ? ? ? ?return TRUE; > @@ -1518,6 +1539,9 @@ static void netreg_properties_reply(struct modem_data *modem, > ? ? ? ? ? ? ? ?return; > ? ? ? ?} > > + ? ? ? if (modem->apn == NULL) > + ? ? ? ? ? ? ? return; > + This doesn't actually work as the 'empty' apn is "". Now that I think about it, it would be safer and easier to just save a boolean apn_is_valid... > ? ? ? ?add_network(modem); > > ? ? ? ?if (modem->active == TRUE) > @@ -2187,6 +2211,7 @@ static void remove_modem(gpointer data) > ? ? ? ?g_free(modem->serial); > ? ? ? ?g_free(modem->name); > ? ? ? ?g_free(modem->imsi); > + ? ? ? g_free(modem->apn); > ? ? ? ?g_free(modem->path); > > ? ? ? ?g_free(modem); > -- > 1.7.9.48.g85da4d > > _______________________________________________ > ofono mailing list > ofono at ofono.org > http://lists.ofono.org/listinfo/ofono From denkenz at gmail.com Mon Feb 27 18:32:55 2012 From: denkenz at gmail.com (Denis Kenzior) Date: Mon, 27 Feb 2012 20:32:55 -0600 Subject: [PATCH 1/2] sim900: Add support for SIMCOM SMS delivery reports In-Reply-To: <1330327184-1497-1-git-send-email-r.r.zaripov@gmail.com> References: <1330327184-1497-1-git-send-email-r.r.zaripov@gmail.com> Message-ID: <4F4C3CD7.7040206@gmail.com> Hi Renat, On 02/27/2012 01:19 AM, r.r.zaripov at gmail.com wrote: > From: Renat Zaripov > > --- > plugins/sim900.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/plugins/sim900.c b/plugins/sim900.c > index f7b1642..b2d1b46 100644 > --- a/plugins/sim900.c > +++ b/plugins/sim900.c > @@ -224,7 +224,8 @@ static void sim900_post_sim(struct ofono_modem *modem) > DBG("%p", modem); > > ofono_phonebook_create(modem, 0, "atmodem", data->modem); > - ofono_sms_create(modem, 0, "atmodem", data->modem); > + ofono_sms_create(modem, OFONO_VENDOR_SIMCOM, "atmodem", I had to fix up a trailing whitespace error at the end of this line. It might be a good idea to configure your editor to show these, or use checkpatch.pl from the Linux kernel to check the patches before submission. > + data->modem); > } > > static void sim900_post_online(struct ofono_modem *modem) Patch has been applied, thanks. Regards, -Denis From denkenz at gmail.com Mon Feb 27 18:33:13 2012 From: denkenz at gmail.com (Denis Kenzior) Date: Mon, 27 Feb 2012 20:33:13 -0600 Subject: [PATCH 2/2] sim900: Disable sending AT+CNMA In-Reply-To: <1330327184-1497-2-git-send-email-r.r.zaripov@gmail.com> References: <1330327184-1497-1-git-send-email-r.r.zaripov@gmail.com> <1330327184-1497-2-git-send-email-r.r.zaripov@gmail.com> Message-ID: <4F4C3CE9.1070208@gmail.com> Hi Renat, On 02/27/2012 01:19 AM, r.r.zaripov at gmail.com wrote: > From: Renat Zaripov > > SIMCOM SIM900 modem module not support AT+CNMA command > > --- > drivers/atmodem/sms.c | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > Patch has been applied, thanks. Regards, -Denis From denkenz at gmail.com Mon Feb 27 18:38:11 2012 From: denkenz at gmail.com (Denis Kenzior) Date: Mon, 27 Feb 2012 20:38:11 -0600 Subject: [PATCH] add some length verification to avoid reading not owned memory In-Reply-To: <4F4C9099.7070609@vfnet.de> References: <4F4B4B0B.7060606@vfnet.de> <1330363339.3392.52.camel@aeonflux> <4F4C9099.7070609@vfnet.de> Message-ID: <4F4C3E13.40906@gmail.com> Hi Jens, > Well, my mail client (Thunderbird) and most modern clients I > know are able to show attached files of text/x-patch (and > similar) type. OTOH I wonder why you want to review patches > in your mail client. Wouldn't it much better to use a It is not that we read patches in the mail client, but that is also useful. The main use-case is to be able to easily comment on the patch if changes are required. And for that we require patches to be sent inline. > specialized too which highlights the changes like > $ gvim "+vert diffpatch " > $ emacs > or > $ xfdiff ? > Don't you have to save the patch files in such cases anyway? > No, the typical workflow (at least for me) is to - 'Save Email' - vim email - if looks okay, git am and compile test Regards, -Denis From jr_extern at vfnet.de Tue Feb 28 08:15:42 2012 From: jr_extern at vfnet.de (Jens Rehsack) Date: Tue, 28 Feb 2012 17:15:42 +0100 Subject: [PATCH 2/3] changing depreciated libtool initialization to modern one In-Reply-To: <1330417045-26518-2-git-send-email-jr_extern@vfnet.de> References: <1330417045-26518-1-git-send-email-jr_extern@vfnet.de> <1330417045-26518-2-git-send-email-jr_extern@vfnet.de> Message-ID: <4F4CFDAE.1090604@vfnet.de> Am 28.02.2012 09:17, schrieb jr_extern at vfnet.de: > From: Jens Rehsack > > --- > Makefile.am | 4 ++++ > configure.ac | 10 ++++++++-- > 2 files changed, 12 insertions(+), 2 deletions(-) > > diff --git a/Makefile.am b/Makefile.am > index c3a4486..bebcb90 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -1,6 +1,10 @@ > > AM_MAKEFLAGS = --no-print-directory > > +LIBTOOL_DEPS = @LIBTOOL_DEPS@ > +libtool: $(LIBTOOL_DEPS) > + $(SHELL) ./config.status libtool > + > gdbus_sources = gdbus/gdbus.h gdbus/mainloop.c gdbus/watch.c \ > gdbus/object.c gdbus/polkit.c > > diff --git a/configure.ac b/configure.ac > index 34cc526..d82569b 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -31,8 +31,8 @@ AC_PROG_INSTALL > m4_define([_LT_AC_TAGCONFIG], []) > m4_ifdef([AC_LIBTOOL_TAGS], [AC_LIBTOOL_TAGS([])]) > > -AC_DISABLE_STATIC > -AC_PROG_LIBTOOL > +dnl AC_DISABLE_STATIC > +dnl AC_PROG_LIBTOOL > > AC_ARG_ENABLE(optimization, AC_HELP_STRING([--disable-optimization], > [disable code optimization through compiler]), [ > @@ -58,6 +58,12 @@ AC_ARG_ENABLE(pie, AC_HELP_STRING([--enable-pie], > fi > ]) > > +dnl LT_INIT should be invoked after all compiler flags checks, because > +dnl of LT_INIT remembers the RPATH stored in test targets which might > +dnl be different for different compiler flags (known issue on AIX) > +LT_INIT([dlopen,disable-static]) This should be +LT_INIT([dlopen disable-static]) > +AC_SUBST([LIBTOOL_DEPS]) > + > AC_CHECK_HEADERS(resolv.h, dummy=yes, > AC_MSG_ERROR(resolver header files are required)) > AC_CHECK_LIB(resolv, ns_initparse, dummy=yes, [ From marcel at holtmann.org Tue Feb 28 08:33:27 2012 From: marcel at holtmann.org (Marcel Holtmann) Date: Tue, 28 Feb 2012 08:33:27 -0800 Subject: [RFC v0] ofono: Only register network when APN is set In-Reply-To: References: <1330363830.3392.59.camel@aeonflux> <1330420763-8244-1-git-send-email-wagi@monom.org> Message-ID: <1330446807.3392.83.camel@aeonflux> Hi guys, > > We should now show a network without an APN. > > --- > > I have not tested this one. But something like this should do > > the trick. Maybe someone with deeper knowledge on the APN > > behavior could explain under which circumstances the APN is set, e.g. > > see the netreg vs apn setting in this patch. Not sure if this is correct. > > > > cheers, > > daniel > > Thanks Daniel. This sort of works after some fixes but it looks like > there are still issues if modem or context properties change. I'll > have a go a fixing it later today. I'm including my initial comments > below for reference (just in case I don't manage to fix them). can you please move this to the ConnMan mailing list. Regards Marcel From oleg.zhurakivskyy at intel.com Wed Feb 29 01:37:45 2012 From: oleg.zhurakivskyy at intel.com (Oleg Zhurakivskyy) Date: Wed, 29 Feb 2012 11:37:45 +0200 Subject: [PATCH 0/2] phonesim: Add timer to set the variable with the delay Message-ID: <1330508267-8656-1-git-send-email-oleg.zhurakivskyy@intel.com> Hello, Please find the changes in order to permit to set variables with the delay (specify the delay in milliseconds): This might be useful to simulate SIM PIN unlocking cases, etc. Regards, Oleg Oleg Zhurakivskyy (2): phonesim: Minor reflow in SimChat::command() phonesim: Add timer to set the variable with the delay src/phonesim.cpp | 49 ++++++++++++++++++++++++++++++++++++++----------- src/phonesim.h | 14 ++++++++++++++ 2 files changed, 52 insertions(+), 11 deletions(-) -- 1.7.5.4 From oleg.zhurakivskyy at intel.com Wed Feb 29 01:37:46 2012 From: oleg.zhurakivskyy at intel.com (Oleg Zhurakivskyy) Date: Wed, 29 Feb 2012 11:37:46 +0200 Subject: [PATCH 1/2] phonesim: Minor reflow in SimChat::command() In-Reply-To: <1330508267-8656-1-git-send-email-oleg.zhurakivskyy@intel.com> References: <1330508267-8656-1-git-send-email-oleg.zhurakivskyy@intel.com> Message-ID: <1330508267-8656-2-git-send-email-oleg.zhurakivskyy@intel.com> Preparation in order to set the variable with the delay, call setVariable() just from one place. --- src/phonesim.cpp | 22 ++++++++++++---------- 1 files changed, 12 insertions(+), 10 deletions(-) diff --git a/src/phonesim.cpp b/src/phonesim.cpp index 09d6306..6931317 100644 --- a/src/phonesim.cpp +++ b/src/phonesim.cpp @@ -331,22 +331,24 @@ bool SimChat::command( const QString& cmd ) for ( int varNum = 0; varNum < variables.size(); ++varNum ) { QString variable = variables[varNum]; QString value = values[varNum]; - if ( value != "*" ) { + QString val; + + if ( value == "*" ) + val = wild; + else { int index = value.indexOf( "${*}" ); - if ( index == -1 ) { - state()->rules()->setVariable( variable, value ); - } else { + if ( index != -1 ) { if ( wild.length() > 0 && wild[wild.length() - 1] == 0x1A ) { // Strip the terminating ^Z from SMS PDU's. wild = wild.left( wild.length() - 1 ); } - state()->rules()->setVariable - ( variable, value.left( index ) + wild + - value.mid( index + 4 ) ); - } - } else { - state()->rules()->setVariable( variable, wild ); + + val = value.left( index ) + wild + value.mid( index + 4 ); + } else + val = value; } + + state()->rules()->setVariable( variable, val ); } // Switch to the new state. -- 1.7.5.4 From oleg.zhurakivskyy at intel.com Wed Feb 29 01:37:47 2012 From: oleg.zhurakivskyy at intel.com (Oleg Zhurakivskyy) Date: Wed, 29 Feb 2012 11:37:47 +0200 Subject: [PATCH 2/2] phonesim: Add timer to set the variable with the delay In-Reply-To: <1330508267-8656-1-git-send-email-oleg.zhurakivskyy@intel.com> References: <1330508267-8656-1-git-send-email-oleg.zhurakivskyy@intel.com> Message-ID: <1330508267-8656-3-git-send-email-oleg.zhurakivskyy@intel.com> In order to set the variable with the delay, specify the delay in milliseconds: --- src/phonesim.cpp | 29 +++++++++++++++++++++++++++-- src/phonesim.h | 14 ++++++++++++++ 2 files changed, 41 insertions(+), 2 deletions(-) diff --git a/src/phonesim.cpp b/src/phonesim.cpp index 6931317..44401fe 100644 --- a/src/phonesim.cpp +++ b/src/phonesim.cpp @@ -268,8 +268,12 @@ SimChat::SimChat( SimState *state, SimXmlNode& e ) } else if ( n->tag == "switch" ) { switchTo = n->getAttribute( "name" ); } else if ( n->tag == "set" ) { - variables += n->getAttribute( "name" ); + QString name = n->getAttribute( "name" ); + variables += name; values += n->getAttribute( "value" ); + int delay = n->getAttribute( "delay" ).toInt(); + if (delay) + delays[name] = delay; } else if ( n->tag == "newcall" ) { newCallVar = n->getAttribute( "name" ); } else if ( n->tag == "forgetcall" ) { @@ -331,6 +335,7 @@ bool SimChat::command( const QString& cmd ) for ( int varNum = 0; varNum < variables.size(); ++varNum ) { QString variable = variables[varNum]; QString value = values[varNum]; + int delay = delays.value(variable, 0); QString val; if ( value == "*" ) @@ -348,7 +353,18 @@ bool SimChat::command( const QString& cmd ) val = value; } - state()->rules()->setVariable( variable, val ); + if (delay) { + QVariantTimer *timer = new QVariantTimer(this->state()->rules()); + + timer->param = QVariant::fromValue(QPairKV(variable, val)); + + timer->setSingleShot( true ); + + connect(timer, SIGNAL(timeout()), this->state()->rules(), + SLOT(delaySetVariable())); + timer->start( delay ); + } else + state()->rules()->setVariable( variable, val ); } // Switch to the new state. @@ -1637,6 +1653,15 @@ void SimRules::delayTimeout() timer->deleteLater(); } +void SimRules::delaySetVariable() +{ + QVariantTimer *timer = (QVariantTimer *)sender(); + QPairKV kv = timer->param.value(); + + setVariable( kv.first, kv.second ); + + delete timer; +} void SimRules::dialCheck( const QString& number, bool& ok ) { diff --git a/src/phonesim.h b/src/phonesim.h index aa693cd..ce69155 100644 --- a/src/phonesim.h +++ b/src/phonesim.h @@ -162,6 +162,7 @@ private: bool eol; QStringList variables; QStringList values; + QMap delays; QString newCallVar; QString forgetCallId; bool listSMS; @@ -315,6 +316,7 @@ private slots: void tryReadCommand(); void destruct(); void delayTimeout(); + void delaySetVariable(); void dialCheck( const QString& number, bool& ok ); private: @@ -373,4 +375,16 @@ public: int channel; }; +class QVariantTimer : public QTimer +{ + Q_OBJECT +public: + QVariantTimer( QObject *parent = 0 ) : QTimer(parent) { } + QVariant param; +}; + +typedef QPair QPairKV; + +Q_DECLARE_METATYPE(QPairKV); + #endif -- 1.7.5.4 From frederic.danis at linux.intel.com Wed Feb 29 05:56:05 2012 From: frederic.danis at linux.intel.com (=?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Danis?=) Date: Wed, 29 Feb 2012 14:56:05 +0100 Subject: [PATCH] phonesim: Fix call scripting capability Message-ID: <1330523765-10592-1-git-send-email-frederic.danis@linux.intel.com> --- doc/scriptable.txt | 6 +++--- src/control.cpp | 3 +++ 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/doc/scriptable.txt b/doc/scriptable.txt index 670bd21..95ae1e1 100644 --- a/doc/scriptable.txt +++ b/doc/scriptable.txt @@ -7,8 +7,8 @@ call, you have to do some operations manually within phonesim GUI). Below are several examples: 1. call.js (stand for incoming call and copy it to /tmp/call/) -tabRegistration.gbIncomingCall.leCaller.text = "12345"; -tabRegistration.gbIncomingCall.pbIncomingCall.click(); +tabCall.gbIncomingCall.leCaller.text = "12345"; +tabCall.gbIncomingCall.pbIncomingCall.click(); Then set the path of script and run the script with its name: @@ -50,6 +50,6 @@ Reference" for details. For example, if you want to know the current incoming number, you may write a script as below: // number.js -tabRegistration.gbIncomingCall.leCaller.text +tabCall.gbIncomingCall.leCaller.text After running the script the similar way as above, you may get the number. diff --git a/src/control.cpp b/src/control.cpp index 2666b4c..ee1e7d8 100644 --- a/src/control.cpp +++ b/src/control.cpp @@ -667,6 +667,9 @@ Script::Script(QObject *obj, Ui_ControlBase *ui) : QDBusAbstractAdaptor(obj) QScriptValue qsTab8 = engine.newQObject(ui->tab_8); engine.globalObject().setProperty("tabPosition", qsTab8); + + QScriptValue qsTab9 = engine.newQObject(ui->tab_9); + engine.globalObject().setProperty("tabCall", qsTab9); } void Script::SetPath(const QString &path, const QDBusMessage &msg) -- 1.7.1 From puffy.taco at gmail.com Wed Feb 29 07:40:59 2012 From: puffy.taco at gmail.com (Mike) Date: Wed, 29 Feb 2012 09:40:59 -0600 Subject: LG VX8360 HFP non-compliance issue In-Reply-To: <4F471E2C.9020208@gmail.com> References: <4F471E2C.9020208@gmail.com> Message-ID: On Thu, Feb 23, 2012 at 11:20 PM, Denis Kenzior wrote: > Hi Mike, > > On 02/23/2012 06:49 PM, Mike wrote: >> I'm getting weird behaviour from an LG VX8360, connected via bluetooth >> HFP. ?When the phone connects, I see a CallAdded signal go out over >> dbus, despite there being no call on the phone itself. ?You can see >> the signal below. ?The LineIdentification held the actual phone number >> of the phone, but I replaced it with "xxxxxxxxxx". ?I also copied in >> the initial RFCOMM communication. ?It looks to me like this phone does >> not comply with the HFP spec in that it returns an answer to AT+CLCC >> when there is no phone call present (and at that, an index of 0). ?It >> also happens that the status is a 6, which does not appear to be a >> valid status in HFPv1.5. ?This just happens to map to the enum >> CALL_STATUS_DISCONNECTED, but I'm guessing this was merely >> coincidence. ?Since the state is broadcast as disconnected, I can >> simply ignore it in my GUI application. ?However, I'm wondering if >> this is something that is better handled in the ofono side? >> >> Thanks, >> Mike >> > > Try the following patch. > > Regards, > -Denis I'm told the patch worked. I don't have direct access to this phone to know exactly what that means, but the issue of incorrectly reporting a phonecall the moment the phone connects is solved. I'm still seeking an answer to whether or not actual phonecalls work. Mike