RE: Segmentation fault on Downlink data transfer
Hi Marcel and Denis There is an issue on downlink data transfer on ifx modem. Please note that ifx modem will switch over to in-kernel MUX for data handling once the kernel MUX driver enhancements for network interface support have been accepted into MeeGo. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH v3] ifx: Adding modem selftest for Infineon modem
plugins/ifx.c | 76
+---
1 files changed, 66 insertions(+), 10 deletions(-)
diff --git a/plugins/ifx.c b/plugins/ifx.c
index c0a69c2..e0eb982 100644
--- a/plugins/ifx.c
+++ b/plugins/ifx.c
@@ -71,6 +71,8 @@
#define GPRS3_DLC 4
#define AUX_DLC 5
+#define IFX_SELF_TESTS_TIMEOUT 10
+
I asked this 3 times now, where is this magic value of 10 seconds coming
from. What is the average expected execution time of each test?
Typical response times are much less than 0.5 sec. 10 seconds is considered
much longer than any normal response time.
+static struct {
+ char *test_desc;
+ char *at_cmd;
+} const mst[] = {
+ { AT Command Test, ATE0 +CMEE=1 }, /* set echo error reporting */
I really don't like to put ATE0 into this. It is not a selftest or test
command.
It acts as a selftest command because if the modem fails to come out of reset
and/or start the AT command parser you will never get an OK back on it. In the
error reporting we would like to be able to distinguish between the AT command
parser not working at all and any subsequent test command failing.
+ { RTC GTI Test, a...@rtc:rtc_gti_test_verify_32khz() },
+ { Device Version Test, a...@vers:device_version_id() },
+ { NULL, NULL }
+};
And I like to still see an answer why we have to trigger selftests here.
To make sure the modem is properly functioning.
Can we just not have one AT command to check the modem health and be
done with it?
The IFX modem we are targetting implements this with two AT commands.
Another question that I did ask is to see some sample results from these
test cases in failure and success case.
Robertino?
Do we actually care about test
description here at all or can we just drop it?
If you prefer cryptic messages then the AT command itself can act as the
description.
Is that preferred?
This is rather pointless. We are not starting a timeout for every single
command. The mux_timeout handling was designed for spawning the overall
setup process and not just one command.
The design documentation wasn't clear on that point. The name mux_timeout
suggested that the timeout only applied to the mux, maybe it should be renamed
to
setup_timeout to better describe the design intention?
Regardless, having a timeout for each command is conceptually cleaner as you
will
know for sure which command is responsible for exceeding the timeout.
Does oFono require the more ambiguous solution with a single timeout?
I am fine with using the established mutliplexer timeout handling here,
but essentially this is not a SELF_TESTS timeout. This is overall setup
timeout. So can we please get the naming right here. I really dislike
code where function names and constants are not named properly. This
causes major confusion later on.
In the patch it is the timeout for the first self test command.
I understand you are thinking about a potential future patch in which it would
be
used as the overall setup timeout, I agree that in that case the name should be
changed accordingly as well, yes.
Cheers,
Waldo
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [RFC PATCH 2/5 v2] cell-info: Header file for cell-info atom
+struct gsm {
+ int lac;
+ int ci;
+ int ta;
+ int no_cells;
+ struct geran_neigh_cell{
+ int arfcn;
+ int bsic;
+ int rxlev;
+
+ } nmr[OFONO_MAX_NMR_COUNT];
+};
What about the frequency of the serving cell? I was under the impression that
there was a need for that one as well.
Even though the serving cell may be included already in the nmr, do you see a
need
to explicitly provide the arfcn, bsic and rxlev of the serving cell as well?
What about LAC and CI for the neighbouring cells?
Cheers,
Waldo
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [RFC PATCH 2/4] cell-info: Header file for cell-info atom
Shouldn't ofono_cell_info_results be defined here and included as an argument
for
ofono_cell_info_query_cb_t ?
Cheers,
Waldo
-Original Message-
From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On Behalf Of
Antti Paila
Sent: Tuesday, December 21, 2010 6:00 AM
To: ofono@ofono.org
Subject: [RFC PATCH 2/4] cell-info: Header file for cell-info atom
---
include/cell-info.h | 66 +++
1 files changed, 66 insertions(+), 0 deletions(-)
create mode 100644 include/cell-info.h
diff --git a/include/cell-info.h b/include/cell-info.h
new file mode 100644
index 000..d9c7810
--- /dev/null
+++ b/include/cell-info.h
@@ -0,0 +1,66 @@
+/*
+ *
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) 2008-2010 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#ifndef __OFONO_CELL_INFO_H
+#define __OFONO_CELL_INFO_H
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+#include ofono/types.h
+
+struct ofono_cell_info;
+
+typedef void (*ofono_cell_info_query_cb_t)(const struct ofono_error *error,
+ void *data);
+
+struct ofono_cell_info_driver {
+ const char *name;
+ int (*probe)(struct ofono_cell_info *ci,
+ unsigned int vendor,
+ void *data);
+ void (*remove)(struct ofono_cell_info *ci);
+ void (*query)(struct ofono_cell_info *ci,
+ ofono_cell_info_query_cb_t,
+ void *data);
+};
+
+struct ofono_cell_info *ofono_cell_info_create(struct ofono_modem *modem,
+ unsigned int vendor,
+ const char *driver,
+ void *data);
+
+void ofono_cell_info_register(struct ofono_cell_info *ci);
+void ofono_cell_info_remove(struct ofono_cell_info *ci);
+int ofono_cell_info_driver_register(struct ofono_cell_info_driver *driver);
+void ofono_cell_info_driver_unregister(struct ofono_cell_info_driver *driver);
+void *ofono_cell_info_get_data(struct ofono_cell_info *ci);
+void ofono_cell_info_set_data(struct ofono_cell_info *ci, void *cid);
+void ofono_cell_info_query_cb(const struct ofono_error *error,
+ void *data);
+
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* __OFONO_CELL_INFO_H */
--
1.7.1
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [PATCH v2] ifx: Adding modem selftest to Infineon modem
@@ -80,6 +82,18 @@ static const char *dlc_nodes[NUM_DLC] = {
/dev/ttyGSM1, /dev/ttyGSM2,
static const char *none_prefix[] = { NULL };
static const char *xdrv_prefix[] = { +XDRV:, NULL };
+static const char *empty_prefix[] = { , NULL };
This is still wrong. See my comment from the original email. I am not
sure you really know what { , NULL } means.
The response doesn't really have a proper prefix (see example below), this way
the entire response ends up in the callback. Is there a better way? Given that
there aren't any URC registered yet, it will not interfere with any other
response. It's obviously not a good idea to use it once the modem is powered up.
a...@vers:device_version_id()
CHIP ID = XXX
FLASH TYPE = YYY
FLASH ID = 0x898881
SmartiUE2 = 37664
RF PMU = 10548
PA PMU = 40244
RF ASM = 0
FEM PA = 21812
OK
Cheers,
Waldo
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: TODO: Network updating the emergency number list
Hi, I have investigated a little bit dynamic updating of emergency numbers by network. So I suggest, I'll register new notification-handler for '+CEN'-report in voicecall-driver. And naturally give those new emergency-numbers for voicecall-atom to be analyzed. The modem will typically already analyze the new emergency-numbers, filter out the ones that are not applicable and merge the numbers from the various sources in the right priority. Some modems are able to communicate the resulting effective list of emergency-numbers, in which case the voicecall-atom should just use the list of emergency numbers reported by the modem without doing any additional merging/analyzing. This also eliminates room for error if the algorithm that the ofono voicecall atom uses differs for some reason from the algorithm used by the modem. For modems that aren't able to communicate their effective list of emergency numbers ofono would still need to create such list by itself as it does now. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] ifx: adding Infineon modem self test
The conclusion was that these two test commands should be issued from the AP to ensure that the modem is functioning properly. I am not aware of the conclusion. My understanding is still that the modem firmware is suppose to do its selftests all by itself. It does not. So what is the reasoning behind doing these selftests from the host. It makes it easier for the host to record diagnostics / error codes this way. At the moment this is limited to recording it in the log file, as oFono doesn't provide a good way for reporting back error conditions when powering up a modem fails. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] ifx: adding Infineon modem self test
Adding Infineon modem selftest to the plugin. It executes couple of AT commands, and based on the responses, it continues with ifx modem enabling or powers the modem down. didn't we conclude that the modem should do all these by itself? My understanding is that the modem executes these. And not that we have to trigger them. The conclusion was that these two test commands should be issued from the AP to ensure that the modem is functioning properly. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 1/5] text-telephony: add public header
+ void (*remove)(struct ofono_ctm *tt); + void (*query_tty)(struct ofono_ctm *tt, + ofono_ctm_query_cb_t cb, + void *data); + void (*set_tty)(struct ofono_ctm *tt, + int enable, I also changed this to ofono_bool_t enable Fyi, I noticed that radio-settings.h has this as an int as well: 67 void (*set_fast_dormancy)(struct ofono_radio_settings *rs, 68 int enable, 69 ofono_radio_settings_fast_dormancy_set_cb_t, 70 void *data); The query callback otoh uses ofono_bool_t. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] doc: Add Location Services API
Conformance testing per 3GPP 34.109s5.4.1.3 requires that
RESET UE POSITIONING STORED INFO is handled.
Similar for 3GPP RESET MS POSITIONING STORED INFO per 3GPP 44.014s12.
As far as I can see there is no provision for that in commands / XML
defined by 27.007.
Would it make sense to add a ResetStoredInfo signal to the DBUS API for
implementation in a modem specific way?
Cheers,
Waldo
-Original Message-
From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On Behalf Of
Sjur Brændeland
Sent: Thursday, November 11, 2010 11:45 AM
To: simon.lethbri...@stericsson.com; ofono@ofono.org
Cc: sjur.brandel...@stericsson.com
Subject: [PATCH] doc: Add Location Services API
From: Sjur Brændeland sjur.brandel...@stericsson.com
As requested, this is our initial proposal for a minimal API
in order to support E911, based on the 27.007 defined AT
commands.
We've discussed internally different names for this API:
AGNSSManager or AssistedGlobalNavigationSatelliteSystem,
but ended up with the simpler LocationServicesManager.
Looking forward to your comments on this API.
Regards,
Simon Lethbridge and
Sjur Brændeland
---
doc/location-services-api.txt | 56 +
1 files changed, 56 insertions(+), 0 deletions(-)
create mode 100644 doc/location-services-api.txt
diff --git a/doc/location-services-api.txt b/doc/location-services-api.txt
new file mode 100644
index 000..18ef230
--- /dev/null
+++ b/doc/location-services-api.txt
@@ -0,0 +1,56 @@
+LocationServicesManager hierarchy
+=
+
+Serviceorg.ofono
+Interface org.ofono.LocationServicesManager
+Object path[variable prefix]/{modem0,modem1,...}
+
+Methodsdict GetProperties()
+
+ Returns properties for the modem object. See
+ the properties section for available properties.
+
+ Possible Errors: [service].Error.InvalidArguments
+
+ void SetProperty(string name, variant value)
+
+ Changes the value of the specified property. Only
+ properties that are listed as read-write are
+ changeable. On success a PropertyChanged signal
+ will be emitted.
+
+ Possible Errors: [service].Error.InvalidArguments
+[service].Error.DoesNotExist
+
+ void SendPositioningControl(string xml_element)
+
+ Send an XML element conforming to the XML DTD for pos
+ as defined in 3GPP 27.007 Table 8.55-2. This xml is
+ used for transferring data associated with positioning
+ requests received via control plane from the network.
+ This includes assistance data requests and the results
+ of positioning procedures. This method maps directly to
+ the 3GPP 27.007 AT+CPOS command.
+
+
+SignalsPropertyChanged(string name, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+ PositioningRequest(string xml_element)
+
+ Receive an XML element conforming to the XML DTD for
+ pos in 3GPP 27.007. This xml is used for transferring
+ data associated with positioning requests received, via
+ control plane, from the network. This includes
+ measurement requests and assistance data. This signal
+ maps directly to the 3GPP defined +CPOSR unsolicited
+ result code.
+
+Properties boolean NetworkInitiatedProceduresEnabled [readwrite]
+
+ If NetworkInitiatedProceduresEnabled is False, then
+ no Position Requests from the network are accepted.
+ The modem is not enabled for positioning requests
+ from the networks view point.
--
1.6.3.3
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [PATCH] doc: Add Location Services API
[Resend without the bottom quote - Damn you Outlook] Conformance testing per 3GPP 34.109s5.4.1.3 requires that RESET UE POSITIONING STORED INFO is handled. Similar for 3GPP RESET MS POSITIONING STORED INFO per 3GPP 44.014s12. As far as I can see there is no provision for that in commands / XML defined by 27.007. Would it make sense to add a ResetStoredInfo signal to the DBUS API for implementation in a modem specific way? Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] ifxmodem: Adding fast dormancy support to Infineon modem
According to the doc I have, modem implementation is quite close: Trigger Fast Dormancy +XFDOR This command triggers fast dormancy if all conditions are passed successful it will be send towards the network. There will be no confirmation if the request was executed or not as in the last extend the full execution belongs to the network. +XFDOR triggers fast dormancy once iff conditions are suitable. oFono expects a mode where fast dormancy is triggered automatically by the modem _anytime_ conditions have been suitable for the duration of a given timeout period. A command for such mode is not yet available in IFX FW as far as I know. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] TODO: Add vCard export to SM/ME stores
Marcel wrote: diff --git a/TODO b/TODO index bf2305b..9dcb43f 100644 --- a/TODO +++ b/TODO @@ -496,3 +496,14 @@ Miscellaneous Priority: Low Complexity: C4 + +- Enable exporting contact information from vCard data to SM and ME stores. + Need to implement a robust vCard parser that can extract at least the + fields supported by the existing phonebook module. Functionality should + be analoguous to existing import functionality. and you will not be able to write a robust vCard parser that we can safely run as root or with any kind of ofonod privileges. It is just way too risky from a security point of view. To support this feature then first we need to convert the current feature into returning a dict. And then have this feature using a dict as input. Does this mean that support for writing to the phonebook is expected to be added to the phonebook modem API as part of ofono core functionality? Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC v2 3/3] ifxmodem: adding modem API to support agps
The error handling in ifx_agps_inject_time_cb needs to have a call to
CALLBACK_WITH_FAILURE.
Calling g_at_chat_register(agd-chat, %%XFTI:, ...) from
ifx_agps_inject_time_cb seems wrong:
- It gets called multiple times
- Are you sure that %XFTI can't come before the OK response?
- agd-chat should be data-chat
#define BUF_LEN should be removed as it isn't used
In ifx_agps_send_lcs_frame the raw_frame isn't hex encoded before it gets
inserted into the AT command.
Cheers,
Waldo
-Original Message-
From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On Behalf Of
Robertino Benis
Sent: Wednesday, November 10, 2010 11:43 AM
To: ofono@ofono.org
Cc: Ahmed, Suhail
Subject: [RFC v2 3/3] ifxmodem: adding modem API to support agps
---
drivers/ifxmodem/agps.c | 413 +++
1 files changed, 413 insertions(+), 0 deletions(-)
create mode 100644 drivers/ifxmodem/agps.c
diff --git a/drivers/ifxmodem/agps.c b/drivers/ifxmodem/agps.c
new file mode 100644
index 000..4e8d427
--- /dev/null
+++ b/drivers/ifxmodem/agps.c
@@ -0,0 +1,413 @@
+/*
+ *
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) 2008-2010 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#define _GNU_SOURCE
+#include string.h
+#include stdlib.h
+#include stdio.h
+#include errno.h
+
+#include glib.h
+
+#include gatchat.h
+#include gatresult.h
+
+#include ofono/log.h
+#include ofono/modem.h
+#include ofono/agps.h
+
+#include util.h
+#include ifxmodem.h
+
+struct agps_data {
+ GAtChat *chat;
+ unsigned int vendor;
+ enum ofono_access_technology rad_acc_tech;
+};
+
+struct ofono_agps;
+static const char *none_prefix[] = { NULL };
+
+static void pos_request_notify(GAtResult *result, gpointer user_data)
+{
+ struct ofono_agps *agps = user_data;
+ int framelen;
+ int frametype;
+ GAtResultIter iter;
+ struct ofono_lcs_frame lcsframe;
+ const char *frame;
+
+ /* Assuming Pos Req format: %XPOSR: frametype,framelen,frame */
+
+ g_at_result_iter_init(iter, result);
+
+ if (!g_at_result_iter_next(iter, %%XPOSR:))
+ return;
+
+ if (!g_at_result_iter_next_number(iter, frametype))
+ return;
+
+ if (!g_at_result_iter_next_number(iter, framelen))
+ return;
+
+ frame = g_at_result_pdu(result);
+
+ DBG(AGPS POS Info: Type = %d Length = %d data = %s,
+ frametype, framelen, frame);
+
+ lcsframe.lcs_frame_type = frametype;
+ lcsframe.frame_length = framelen;
+ lcsframe.raw_frame = (unsigned char *)frame;
+
+ ofono_agps_lcs_frame_notify(agps, lcsframe);
+}
+
+static void inj_time_notify(GAtResult *result, gpointer user_data)
+{
+
+ struct cb_data *cbd = user_data;
+ struct agps_data *data = cbd-user;
+ ofono_agps_inject_time_cb_t cb = cbd-cb;
+ struct ofono_lcs_radio_fn rf;
+ struct ofono_error error = { .type = OFONO_ERROR_TYPE_NO_ERROR };
+ GAtResultIter iter;
+
+ g_at_result_iter_init(iter, result);
+
+ if (!g_at_result_iter_next(iter, %%XFTI:))
+ return;
+
+ if (data-rad_acc_tech == RADIO_ACCESS_TECHNOLOGY_GSM) {
+
+ int fn; /* range 0 - 2715647 (2048*26*51) */
+ int ts; /* range 0 - 7 */
+ int tsb;/* range 0 - 156 */
+ int ta; /* range 0 - 63 */
+ int ba; /* range 0 - 1023 */
+ int bc; /* range 0 - 64 */
+
+ /* %XFTI:frameNum,TimeSlot,TimeSlotBit,TimeAdv,
+ * ChannelNum,ChannelId
+ */
+ if (!g_at_result_iter_next_number(iter, fn))
+ goto err;
+
+ if (!g_at_result_iter_next_number(iter, ts))
+ goto err;
+
+ if (!g_at_result_iter_next_number(iter, tsb))
+ goto err;
+
+ if (!g_at_result_iter_next_number(iter, ta))
+ goto err;
+
+ if (!g_at_result_iter_next_number(iter, ba))
+ goto err;
+
+ if (!g_at_result_iter_next_number(iter, bc))
+ goto err;
+
+
RE: [RFC v2 3/3] ifxmodem: adding modem API to support agps
this mailing list does NOT allow top posting and you know this. I indeed realized this about a second after I pressed send. My initial response was to use Outlook's recall function to correct my mistake... luckily sanity prevailed. I am very sorry about this transgression. I will now sulk in the corner for a while. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC 1/3] doc: addidng documentation for basic assisted gps
oFono is strict CamelCase, even for abbreviations. You do this correctly above (AgpsManager) but not here. Please be consistent. And it might be a good idea to not have abbreviations at all. What does LCS stand for in this case? It refers to terminology from 3GPP TS 04.31: RRLP - Radio Resource LCS Protocol LCS - Location Services + The raw frame data is formatted as the concatenated + sequence of the two digit hexadecimal representation + of each of its octets. Example: 00FC2345 Sending hex-encoded data screams as being non-portable and AT command modem specific. Is this really your intent here? The intent is to send an array of octets. A string seemed a debug-friendly way of mapping it onto a DBUS API, but other suggestion for a suitable DBUS type are welcome. + void RequestFineTimeInjection(string rat, uint16 pulselength) It seems to me that making the upper layers pass in the rat as a parameter to this function is a pretty bad idea. You should either have the atom figure this out if it can (e.g. by using netreg atom) or have the driver take care of this directly. I was asked to add it as the AGPS manager that makes the request presumes a certain RAT and there is no point in generating the pulse if the RAT has changed since. See also http://lists.ofono.org/pipermail/ofono/2010-May/002347.html + + FineTimeInjectionNotification(dict radioframenumber) + + Notification about fine time injection pulse + generated by modem. The radioframenumber dict + is defined as follow: + Why is this returned in a separate signal as opposed to a reply to the RequestFineTimeInjection method call? The concern was that the reply would not be immediate, but I don't think it's that much delayed that it runs in any DBUS timeouts, so I think it can be turned into a reply instead. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC] AGPS Support
For other modems sending the raw RRC/RRLP frames I guess the transcoding to XML would need to happen in the ofono driver or in ofono core if you want to expose an oFono XML API. so here is my take on XML. If we have to parse it, then in general that is a bad idea. Creating XML is just fine. You need both as it's not only a matter of converting the raw RRC/RRLP frames from the modem to XML, but the responses from the GPS engine are presumably in XML format as well then and the modem driver would need to parse that and re-create RRC/RRLP frames again (for modem that expects raw RRC/RRLP frames). See the tables in section 8.55 of 27.007 for the XML schemas. It refers to the ASN.1 syntax for the definition of the value ranges. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: RFC: Supporting STK without PDUs
We have already had a discussion on this one when designing the current stk modem API. The bottom line is that oFono tries to keep its core - modem interfaces minimal and exposing the entirety of stkutil.h as official API is definitely too much. So right now you will need to re-encode into PDU form to support such modems (or ask the vendor to give the raw pdus) While this is a bit of a performance hit, it isn't too bad as the PDUs are always smaller than 256 bytes. In that case we would still want to use functionality from stkutil.c to do the actual re-encoding. So in my mind it is a trade-off between forking stkutil.c for one or more modem-plugins or exporting stkutil.h Given that the type definitions in stkutil.h are a relative straightforward mapping of TS 102.223 and friends, it may not qualify as a minimal API but it will be a rather stable API. So I would like to ask to reconsider exposing the type definitions as part of the official oFono modem API. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Startup sequence for Online / offline mode
Modem drivers that support Online / offline mode default to offline when oFono loads them. Which component is responsible for calling oFono and switch the modem to online mode? Will that component be part of MeeGo? Cheers, Waldo -- Intel Corporation - Hillsboro, Oregon Ultra Mobility Group - Platform Software Architecture Tel: +1 503 264 6237 - Mobile: +1 503 703-7327 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Startup sequence for Online / offline mode
Modem drivers that support Online / offline mode default to offline when oFono loads them. Which component is responsible for calling oFono and switch the modem to online mode? Will that component be part of MeeGo? This feature is still highly experimental and not all of the details have been figured out (only ISI supports it today). Our current thinking is to have ConnMan manage the Online state of the GSM modems (e.g. replace Powered handling with Online handling.) However, we're still pretty far from that; we'd need to migrate all existing modem drivers to manage Online/Offline state properly first. I agree with Denis here. The Online state needs to be controlled by ConnMan, but we haven't done that change yet. It would break current users since we haven't migrated all modems to handle Online state properly or emulate it if needed. My understanding was that the Online state would be initialized by a component like Telepathy-ring or some sort of system management daemon to ensure that the dialer is up and running and able to accept calls before the Online state is entered. If ConnMan initializes the Online state, how is it ensured that all required clients (Dialer, SMS, etc.) have registered already? Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: USSD support in ofono-0.25
s s wrote: supplementaryservices-api.txt is not available in doc folder in ofono-0.25.tar.gz ,is there any other location to find it? http://git.kernel.org/?p=network/ofono/ofono.git;a=blob_plain;f=doc/supplementaryservices-api.txt;hb=7cd09ee21aff49afc7f5678cb56f8c5300ca42b4 Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Monitor current technology
So my current thinking is to drop any Tech reporting in gprs atom for now. At least until we actually find a usecase for EPSB/CPSB style reporting. What about the CGREG style tech reporting? Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[RFC] AGPS support
Please find attached a proposal for both a DBUS and Modem API for AGPS support.
This proposal introduces two AGPS features:
1) Fine time injection - the cellular modem has access to accurate timing
information that can help a GPS device to get a quicker fix. If the modem and
GPS device are separate components a handshake mechanism is required to forward
the timing information from the modem to the GPS. A typical approach is to have
a hardware signal between the modem and GPS device that can carry a timing
pulse. In addition signalling through software is required to request such
timing pulse and to associate the correct Universal Time with the generated
pulse.
2) Control Plane Assistance Data and Position Requests - The Mobile Network is
able to provide assistance data for GPS devices through the control plane. This
assistance data can help a GPS device to get a quicker fix. In addition the
control plane can be used by the Mobile Network to request a GPS enabled
Mobile Device for its location. This latter functionality is needed to meet
E911 requirements [1]. A typical sequence looks as follow:
Mobile Network Mobile Device
--- Assistance Data ---
--- Position Request --
-- Position Response --
[1] http://en.wikipedia.org/wiki/Enhanced_911
Cheers,
Waldo
---
doc/agps-api.txt | 98 +++
include/agps.h | 135 ++
2 files changed, 233 insertions(+), 0 deletions(-)
create mode 100644 doc/agps-api.txt
create mode 100644 include/agps.h
diff --git a/doc/agps-api.txt b/doc/agps-api.txt
new file mode 100644
index 000..7245eac
--- /dev/null
+++ b/doc/agps-api.txt
@@ -0,0 +1,98 @@
+AgpsManager hierarchy
+===
+
+Serviceorg.ofono
+Interface org.ofono.AgpsManager
+Object path[variable prefix]/{modem0,modem1,...}
+
+Methodsdict GetProperties()
+
+ Returns properties for the modem object. See
+ the properties section for available properties.
+
+ Possible Errors: [service].Error.InvalidArguments
+
+ void SetProperty(string name, variant value)
+
+ Changes the value of the specified property. Only
+ properties that are listed as read-write are
+ changeable. On success a PropertyChanged signal
+ will be emitted.
+
+ Possible Errors: [service].Error.InvalidArguments
+[service].Error.DoesNotExist
+
+ void SendLCSFrame(string framedata)
+
+ Send a LCS position protocol frame to the Mobile
+ Network. The LCS frame typically represents a
+ Position Response.
+ The raw frame data is formatted as the concatenated
+ sequence of the two digit hexadecimal representation
+ of each of its octets. Example: 00FC2345
+
+ void RequestFineTimeInjection(uint16 pulselength)
+
+ Request modem to generate a fine time injection
+ pulse. pulselength is the duration of the pulse
+ expressed in radio frames.
+
+
+SignalsPropertyChanged(string name, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+ IncomingLCSFrame(string framedata)
+
+ LCS positioning protocol frame received from the
+ Mobile Network. The LCS frame typically represents
+ Assistance Data, a Position Request or a combination
+ of both.
+ The raw frame data is formatted as the concatenated
+ sequence of the two digit hexadecimal representation
+ of each of its octets. Example: 00FC2345
+
+ FineTimeInjectionNotification(dict radioframenumber)
+
+ Notification about fine time injection pulse
+ generated by modem. The radioframenumber dict
+ is defined as follow:
+
+ string AccessTechnology
+ gsm or umts
+
+ uint32 TdmaFrameNumber (gsm only)
+ range 0 - 2715647 (2048*26*51)
+
+ uint16 TdmaTimeslot (gsm only)
+ range 0 - 7
+
+ uint16 TimeslotBit (gsm only)
+ range 0 - 156
+
+ uint16 TimingAdvance (gsm only)
+ range 0 - 63
+
+ uint16 BcchArfcn (gsm only)
RE: oFono status?
http://git.kernel.org/?p=network/ofono/ofono.git;a=tree;f=doc; has useful documentation on the external DBUS API. A while back the validation folks where posting test-reports [1], but I haven't seen those in a while. [1] http://lists.ofono.org/pipermail/ofono/2010-February/001180.html Cheers, Waldo -- Intel Corporation - Hillsboro, Oregon Ultra Mobility Group - Platform Software Architecture Tel: +1 503 264 6237 - Mobile: +1 503 703-7327 From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On Behalf Of Mats BERGSTROM Sent: Tuesday, May 04, 2010 4:41 AM To: ofono@ofono.org Subject: oFono status? Hi, What is the plans for the oFono in conjunction with the MeeGo project? Being one of the basic components of the MeeGo, what is the current status today and are there any components lacking for it to be production level? If so, what do the plans look like for bringing it to that? Also, where can I find more documentation than the image at http://ofono.org/documentation? Best Regards /Mats Bergström [cid:image002.gif@01CAEB61.DAE55C60] Mats Bergström Application System Architect ST-Ericsson Nya Vattentornet SE-22183, Lund Sweden www.stericsson.comhttp://www.stericsson.com Office: +46 46 104260 Mobile: +46 76 139 5856 Fax: +46 46 106274 Email: mats.m.bergst...@stericsson.commailto:mats.m.bergst...@stericsson.com This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interception, unauthorized amendment, tampering and viruses, and we only send and receive emails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. inline: image002.gif___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 2/2] Added SQLite history plugin
Hi Denis, Actually our apps listen for the IncomingMessage signal, and store the SMS in an internal database. At some point by design, a restart, a crash or other reasons, it may happen that apps are down while ofono and the modem are up, in that case we lose incoming messages. A similar lack of robustness exists at the modem API side as well, if oFono crashes/runs out of battery after receiving the message from the modem driver the message is lost. There is no provision in the SMS modem API to signal back to the modem driver that the message has been successfully stored on the APE. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 2/2] Added SQLite history plugin
Hi Waldo, Hi Denis, Actually our apps listen for the IncomingMessage signal, and store the SMS in an internal database. At some point by design, a restart, a crash or other reasons, it may happen that apps are down while ofono and the modem are up, in that case we lose incoming messages. A similar lack of robustness exists at the modem API side as well, if oFono crashes/runs out of battery after receiving the message from the modem driver the message is lost. There is no provision in the SMS modem API to signal back to the modem driver that the message has been successfully stored on the APE. If oFono crashes/runs out of battery here the driver is gone along with oFono. Notifying it of anything is not going to help ;) Currently the modem driver acknowledges the PDU right away. If there was a notification back to the modem driver, the PDU acknowledgement could be delayed till that point in time. If something bad happens in between, either the modem or the network can hold on to the PDU and redeliver once oFono is up and running again. Looking at at_cmt_notify() the current implementation might have that affect already, as AT+CNMA is only send after calling ofono_sms_deliver_notify(). So as long as ofono_sms_deliver_notify() is handled synchronously and ensures that the PDU is stored one way or another before returning, it will work in case of a crash. (Would like to see assumptions like that called out in the code) That said, if your storage has issues (disk full?) there is currently no way to let the modem driver know that delivery was unsuccessful. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 2/2] Added SQLite history plugin
Bastian, Waldo ha scritto: The message handling in this patch seems to be vulnerable to SQL injection attacks. See http://en.wikipedia.org/wiki/SQL_injection Cheers, Waldo Hi Waldo, I didn't think of a message carrying an SQL injection :) Honestly I would use prepared statement since start of the job but I didn't manage how to do them in SQLite but I agree with you they're more secure and the code is cleaner, so I converted the source to them after studying their use. Thanks, much better :-) Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Access to SIM card when Modem is not Powered
Pekka Pessi wrote: I've been porting the N900 modem control code to oFono. The semantics of Powered is fine with respect of the atoms, in other words, if the modem crashes and boots itself, all the atoms are flushed nicely. When powering up, the Powered can be set to true when the modem is really up and running. Do you have an overview of the different modes and transitions that the N900 modem control is using today? Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: RFC: Neighbouring Cell Info, take 2
to, 2010-02-11 kello 20:25 +0100, ext Bastian, Waldo kirjoitti: void ofono_cell_info_query(struct ofono_cell_info *ci, ofono_cell_info_query_cb_t cb, void *data); What's this for? It's basically ofono_cell_info_driver-query(...) for use by a plugin after it has acquired the atom, something like: cell_info_atom = __ofono_modem_find_atom(modem, OFONO_ATOM_TYPE_CELL_INFO); cell_info = __ofono_atom_get_data(cell_info_atom); ofono_cell_info_query(cell_info, plugin_query_cb, plugin_data); Right, but if the atom already exposes a D-Bus API, what is the purpose of this plugin interface? It's either a D-Bus API or a plugin interface and Denis indicated a preference for a plugin interface over a D-Bus API. I think his main concern was over the maturity of the API, so maybe he can be pursuaded otherwise now that this is based off the OMA SUPL standard. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: RFC: Neighbouring Cell Info, take 2
struct ofono_cell_info_driver {
const char *name;
int (*probe)(struct ofono_cell_info *ci, unsigned int vendor,
void *data);
void (*remove)(struct ofono_cell_info *ci);
void (*query)(struct ofono_cell_info *ci,
ofono_cell_info_query_cb_t cb,
void *data);
};
void ofono_cell_info_query(struct ofono_cell_info *ci,
ofono_cell_info_query_cb_t cb, void *data);
What's this for?
It's basically ofono_cell_info_driver-query(...) for use by a plugin after it
has acquired the atom, something like:
cell_info_atom = __ofono_modem_find_atom(modem, OFONO_ATOM_TYPE_CELL_INFO);
cell_info = __ofono_atom_get_data(cell_info_atom);
ofono_cell_info_query(cell_info, plugin_query_cb, plugin_data);
Cheers,
Waldo
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RFC: Neighbouring Cell Info, take 2
Hi,
Revisited proposal for neighbouring cell info based on previous feedback:
- Low-level driver API instead of oFono.org DBUS API
- Polling based, no automatic periodic updates
- Follows definitions in OMA SUPL v2.0
I'm not particular fond of the nested list - wcdma.
measured_results_list[].cell_measured_results[], maybe flatten that into a
single list?
Cheers,
Waldo
/*
*
* oFono - Open Source Telephony
*
* Copyright (C) 2010 Intel Corporation.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*
*/
#ifndef __OFONO_CELL_INFO_H
#define __OFONO_CELL_INFO_H
#ifdef __cplusplus
extern C {
#endif
#include ofono/types.h
struct ofono_cell_info;
enum ofono_cell_info_type {
OFONO_CELL_INFO_GSM = 0,
OFONO_CELL_INFO_WCDMA = 1,
};
struct ofono_cell_info_results {
enum ofono_cell_info_type rat;
char mcc[OFONO_MAX_MCC_LENGTH + 1];
char mnc[OFONO_MAX_MNC_LENGTH + 1];
union {
struct {
int lac;/* Location Area Code (0.65535) */
int ci; /* Cell Identity (0..65535) */
int ta; /* Timing Advance (0..255), -1 =
unsupported */
int no_cells; /* Number of valid nmr entries (1..15)
*/
struct {
int arfcn; /* ARFCN of the channel (0..1023) */
int bsic; /* BSIC of the channel (0..63) */
int rxlev; /* Measured power of the channel
(0..63) Subtract 110 to get power in dBm */
} nmr[15];
} gsm;
struct {
int uc; /* Cell Identity, composed of
RNC-ID and C-ID (0..268435455) */
int dl_frequency; /* (0..16383), -1 = unsupported
*/
int ul_frequency; /* (0..16383), -1 = unsupported
*/
int scrambling_code;/* Primary scrambling code
(0..511) */
int no_freq;/* Number of valid
measured_results_list entries (1..8) */
struct {
int dl_frequency; /* (0..16383), -1 =
unsupported */
int ul_frequency; /* (0..16383), -1 =
unsupported */
int rssi; /* UTRA-CarrierRSSI
(0..76), -1 = unsupported */
int no_cells; /* Number of valid
cell_measured_results entries (0..32) */
struct {
int ci; /* Cell Identity
(0..268435455), -1 = unsupported */
int scrambling_code; /* Primary
scrambling code (0..511) */
int ecn0; /* (0..49), -1 =
unsupported */
int rscp; /* cpich-RSCP per [3GPP
RRC] (0..127), -1 = unsupported */
int pathloss; /* (46..158), -1 =
unsupported */
} cell_measured_results[32];
} measured_results_list[8];
} wcdma;
};
};
typedef void (*ofono_cell_info_query_cb_t)(const struct ofono_error *error,
const struct
ofono_cell_info_results results,
void *data);
struct ofono_cell_info_driver {
const char *name;
int (*probe)(struct ofono_cell_info *ci, unsigned int vendor,
void *data);
void (*remove)(struct ofono_cell_info *ci);
void (*query)(struct ofono_cell_info *ci,
ofono_cell_info_query_cb_t cb,
void *data);
};
void ofono_cell_info_query(struct ofono_cell_info *ci,
ofono_cell_info_query_cb_t cb, void *data);
int ofono_cell_info_driver_register(const struct ofono_cell_info_driver *d);
void ofono_cel_info_driver_unregister(const struct ofono_cell_info_driver *d);
struct ofono_cell_info *ofono_cell_info_create(struct ofono_modem *modem,
unsigned int
vendor,
RE: [PATCH 1/3] Add radio access atom and driver API
This atom provides access to the modem's radio access properties. It currently includes a single rw property, namely the radio access selection mode setting. It might be helpful to include the API documentation too. One thing I don't like is the name RadioAccess. The connotation is a bit too low-level. Perhaps BandSelection? RadioBandSelection? Radio access is a pretty broad high level concept. It's one of those black boxes you draw somewhere near the bottom of a phone architecture diagram, so in that sense it is low-level but that comes with the territory. BandSelection in my mind implies frequency band selection, which is a narrow aspect of radio access. The 2G/3G selection covered with this patch is about radio access _technology_, which is distinct from the actual frequency bands used by those technologies. I think RadioAccess is a fairly good name for an interface that has the potential to cover various radio related settings. Use case for 2G/3G selection: http://androidcommunity.com/forums/archive/index.php/t-11857.html Use case for band selection: http://support.t-mobile.com/doc/tm53294.xml?docid=5222referring%20topicid=67A2L.SERVICE=Referring%20TopicID/DocID%20List%20Index=ynavtypeid=2pagetypeid=26prevPageIndex=3 Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 1/3] Add radio access atom and driver API
People on this list keep forgetting two things: 1. We're not designing a kitchen sink API here. Most of the 'radio related settings' will simply never be exposed, nobody really cares what UMTS channel he/she is currently on. 2. We're designing the API to be easy to use for everyone, not just GSM geeks. In your AM/FM Tuner the 'Band' button switches between AM and FM. You immediately know what the button does. The interface name in oFono should ideally give the user an immediate idea of what it is for. In my view RadioAccess does not fit this ideal. Perhaps BandSelection is the wrong name too, lets come up with a better one. StuffThatCustomerServiceTellsYouToUseWhenThingsDontQuiteWork Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: RFC: API for Neighbouring Cell Info
Hi Aki, Honestly I don't like either approach, the Agent pattern would be a much better fit here. This would allow us to specify the polling/update interval and stop neighbor cell updates when no one is interested in them. In my experience, the positioning guys don't need periodic updates at all. The data needs to be fetched on demand. Like whenever the user starts up a location-aware application. Fair enough, but we also have to consider the case of multiple applications being interested in this information. We can't assume that it will be polled on demand by just one... Ny understanding is that typically there would be a location service that queries this information from oFono and converts it into actual coordinates through voodoo and black magic and that location-aware applications will ask this location service for coordinates. E.g. you would have something like GeoClue providing a single API for providing coordinates to applications and under GeoClue there is the location service, and the location service in turn talks to oFono. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] G1: Add an SMS quirk for CNMI mode
- /* Mode doesn't matter, but sounds like 2 is the sanest option */ - if (!append_cnmi_element(buf, len, cnmi_opts[0], 2310, FALSE)) + if (data-vendor == OFONO_VENDOR_HTC_G1) + /* The G1 advertises support for mode 2, but returns an error + * if we attempt to actually use it. */ + mode = 1; + else + /* Sounds like 2 is the sanest mode */ + mode = 2310; + + if (!append_cnmi_element(buf, len, cnmi_opts[0], mode, FALSE)) return FALSE; Instead of having vendor checks all over the place, wouldn't it be cleaner if the plugin had a way to provide/fix cnmi_opts? Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: GPRS support for Ofono
This really belong in the kernel. Only the kernel can reliably know when a network interface has been brought down and notify the interested applications with the statistics. You're missing the point. Yes, any body can extract the statistics for a running context. But data counters are cumulating. To compute the sum properly, there are but two options: # Either the GPRS middleware requests kernel per-interface statistics right before destroying the interface, and sums with the earlier total. # Or the modem does it internally. I know why you want this, but I'm still against the counter being an oFono driver API. There needs to be a proper kernel interface that signals the application when an interface has gone away with the rx/tx details. This way we handle this generically for all modems without relying on some intrinsic hardware capabilities. This still doesn't solve the case where the modem is accessed from a PC client and forwards PPP data as that data will not go through any network interface, e.g. BT DUN or USB tethering. The modem is really in the best position to provide the most reliable information on data usage. You can still use statistics from the network interfaces as a fall-back in case the modem can not provide this information. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: GPRS support for Ofono
I am still not seeing the point in what suspended will do for us and the UI. And that Maemo 5 exposed such a state in the UI is not an argument to keep doing it. I asked this before, what are we suppose to be doing when we get signaled suspended? User, as well as intelligent (connectivity-aware) applications, need to know about this so that they understand why Internet is momentarily broken. It's as simple as that. +1 Oh we could also use the network device carrier flag, and then use Netlink (and we probably should do that too), but we all know how horrible Netlink is from userland. Using IFF_RUNNING and IFF_LOWER_UP sounds more reasonable then some suspended state. IF_OPER_DORMANT seems a more accurate reflection of the state. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: GPRS support for Ofono
I know why you want this, but I'm still against the counter being an oFono driver API. There needs to be a proper kernel interface that signals the application when an interface has gone away with the rx/tx details. This way we handle this generically for all modems without relying on some intrinsic hardware capabilities. This still doesn't solve the case where the modem is accessed from a PC client and forwards PPP data as that data will not go through any network interface, e.g. BT DUN or USB tethering. The cases you describe imply that oFono is not even in control of the gprs context. How would we track/report the tx/rx statistics in that case? It's probably difficult if the PC client is allowed to redefine GPRS contexts, but otherwise oFono should at least be able to report the total tx/rx for the context's it has defined. The BT DUN / USB bridge could call into oFono and trigger a poll of all the stats to update them, e.g. when a BT DUN connection is disconnected. The modem is really in the best position to provide the most reliable information on data usage. You can still use statistics from the network interfaces as a fall-back in case the modem can not provide this information. I don't disagree, but not every modem can track these statistics and this isn't described by 27.007. I suggest the initial support should be enabled by the modem driver implementing a custom D-Bus interface and expose these details however it wishes. The modem driver has no desires of its own :-) It really comes down to what the UI needs and I doubt that the UI wants to deal with this on a modem by modem basis, but sure it's a possibility. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
